On 1/31/21 11:11 AM, Steven Schveighoffer wrote:
> This is how I would do it:
> 
> i"Hello, ${var.withFormat!"%45s"} world";
> 
> (where withFormat provides a toString overload that works with idup). No extra intermediate allocations necessary.

I wonder if we can define a nice convention by the use of past tense vs. active.

format!"%45s"(val) -> format using this spec the following values

val.formatted!"%45s" -> value formatted with this spec

We have just a bit of that with sort/sorted.

Maybe flesh that up in phobos 2.0 :o).

On 1/31/2021 3:28 AM, Adam D. Ruppe wrote:
> On Sunday, 31 January 2021 at 05:37:09 UTC, Walter Bright wrote:
>> Also, needing the GC for this to work with printf is a problem, as one cannot use it with betterC.
> 
> This DIP does not require the GC to work with printf.
> 
> The little forwarding function Steven demonstrated is 100% compatible with betterC.

Thank you for clarifying.

On Sunday, 31 January 2021 at 15:54:12 UTC, Steven Schveighoffer wrote:
>
> I think we're going to end up with something like this. The more I think about it, the more I feel that having a primary type be the tuple is required.
>
> [snip]

Good. Remember though - you still have to do something to the `mixin(i"...")` case Backus warned about. My suggestion about the user manually selecting the type is one option, but not the only one. Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.

On Monday, 1 February 2021 at 16:00:54 UTC, Dukc wrote:
> Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.

Yeah, the grammar could always just special case overload mixin(Interpolated).

Or .stringof could be redefined so like interp!"foo".stringof == "foo" or whatever.

.... or just ban it. Make mixin(i"...") a compile error so the user can do their own thing.


Frankly I think it is madness that mixin uses stringof in the first place since it is so poorly defined. The spec specifically says:

https://dlang.org/spec/property.html#stringof

Implementation Defined: The string representation for a type or expression can vary.

Best Practices: Do not use .stringof for code generation. Instead use the identifier trait, or one of the Phobos helper functions such as std.traits.fullyQualifiedName.


So why the heck is that built into the language?!?

On 2/1/21 11:00 AM, Dukc wrote:
> On Sunday, 31 January 2021 at 15:54:12 UTC, Steven Schveighoffer wrote:
>>
>> I think we're going to end up with something like this. The more I think about it, the more I feel that having a primary type be the tuple is required.
>>
>> [snip]
> 
> Good. Remember though - you still have to do something to the `mixin(i"...")` case Backus warned about. My suggestion about the user manually selecting the type is one option, but not the only one. Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.
> 

I think we have to special case mixin and assert, which is reasonable, since this is a language feature.

-Steve

On Monday, 1 February 2021 at 16:10:46 UTC, Adam D. Ruppe wrote:
> On Monday, 1 February 2021 at 16:00:54 UTC, Dukc wrote:
>> Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.
>
> Yeah, the grammar could always just special case overload mixin(Interpolated).
>
> Or .stringof could be redefined so like interp!"foo".stringof == "foo" or whatever.

One problem: `.stringof` is supposed to be a source representation. "foo" in source represents a string, not part of an interpolated string.

>
> .... or just ban it. Make mixin(i"...") a compile error so the user can do their own thing.

I advise against that.

Quoting https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/:
> String interpolation
> 
> I was initially against this, but the more I think about it the more it seems to make
> sense for D. Why? String mixins. Code generation is one of D’s greatest strengths, and
> token strings enable visually pleasing blocks of code that are actually “just strings”.
> String interpolation would make them vastly easier to use. As it happens, there’s a draft > DIP for it in the pipeline.

You don't want to require the user add an extra symbol for every interpolated string in it's most important use case.

On Monday, 1 February 2021 at 16:16:11 UTC, Steven Schveighoffer wrote:
> On 2/1/21 11:00 AM, Dukc wrote:
>> Good. Remember though - you still have to do something to the `mixin(i"...")` case Backus warned about. My suggestion about the user manually selecting the type is one option, but not the only one. Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.
>> 
>
> I think we have to special case mixin and assert, which is reasonable, since this is a language feature.

Please, no. This way leads to the Dark Side.

On Monday, 1 February 2021 at 16:22:02 UTC, Dukc wrote:
> One problem: `.stringof` is supposed to be a source representation. "foo" in source represents a string, not part of an interpolated string.

Oh I just thought about it some more and interp isn't the problem.

Automatic stringof is madness to begin with since this problem isn't unique to this feature. mixin(genric_type.stringof) is *always* wrong due to the mismatched scope so there's no good reason to have such a broken feature built into the language.

Consider this too: mixin(i"hi ${a+b}") - without the special rule - would expand to mixin("hi ", "a+b") so even that a+b is interpreted in a different scope.

So we *have* to special case this somehow to work around this broken mixin string "feature". Ugh.

On 2/1/21 11:37 AM, Paul Backus wrote:
> On Monday, 1 February 2021 at 16:16:11 UTC, Steven Schveighoffer wrote:
>> On 2/1/21 11:00 AM, Dukc wrote:
>>> Good. Remember though - you still have to do something to the `mixin(i"...")` case Backus warned about. My suggestion about the user manually selecting the type is one option, but not the only one. Perhaps mixins can be special case to invoke `idup` if any of their arguments are instanced from `interp`.
>>>
>>
>> I think we have to special case mixin and assert, which is reasonable, since this is a language feature.
> 
> Please, no. This way leads to the Dark Side.

There is literally no use case for calling mixin with the expanded tuple. If we are doing rewrites, here is one place we should always do it.

Besides, we are looking for consistency, and something.stringof is not consistent as pointed out already. The idup call will be consistent.

-Steve

On Monday, 1 February 2021 at 16:40:54 UTC, Adam D. Ruppe wrote:
> Consider this too: mixin(i"hi ${a+b}") - without the special rule - would expand to mixin("hi ", "a+b") so even that a+b is interpreted in a different scope.

No, you've added an extra level of quoting by mistake. It would expand to `mixin("hi ", a+b)`. The expression `a+b` would be evaluated using CTFE, and then .stringof (i.e., the .toString method) would be called on the result. Here's the relevant frontend code:

https://github.com/dlang/dmd/blob/v2.095.0/src/dmd/expressionsem.d#L91