February 02, 2021
On 02/02/2021 5:41 AM, Steven Schveighoffer wrote:
> 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.

enum Prop = ...;
enum PropValue = ...;

mixin(i"obj.${Prop} = PropValue;");

Are you referring to that? Because that could be useful.
February 01, 2021
On Monday, 1 February 2021 at 17:19:09 UTC, rikki cattermole wrote:
> On 02/02/2021 5:41 AM, Steven Schveighoffer wrote:
>> 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.
>
> enum Prop = ...;
> enum PropValue = ...;
>
> mixin(i"obj.${Prop} = PropValue;");
>
> Are you referring to that? Because that could be useful.

It doesn't work the way you think it does.

https://forum.dlang.org/post/bvdfzfbqybarvpgydewx@forum.dlang.org
February 01, 2021
On Monday, 1 February 2021 at 17:06:36 UTC, Paul Backus wrote:
> No, you've added an extra level of quoting by mistake.

oh yeah, that's right.

So we could prolly just define the stringof of interp to be slightly less crazy (the source version either being the proper fqn or the literal itself) and then there's no special case in mixin.
February 01, 2021
On Monday, 1 February 2021 at 17:52:35 UTC, Adam D. Ruppe wrote:
> On Monday, 1 February 2021 at 17:06:36 UTC, Paul Backus wrote:
>> No, you've added an extra level of quoting by mistake.
>
> oh yeah, that's right.
>
> So we could prolly just define the stringof of interp to be slightly less crazy (the source version either being the proper fqn or the literal itself) and then there's no special case in mixin.

Well, you can't define .stringof in user code--at least, not in a way the compiler will recognize--so you'd have to make the interp literals into a new builtin type rather than a library template.
February 01, 2021
On 2/1/21 12:19 PM, rikki cattermole wrote:
> On 02/02/2021 5:41 AM, Steven Schveighoffer wrote:
>> 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.
> 
> enum Prop = ...;
> enum PropValue = ...;
> 
> mixin(i"obj.${Prop} = PropValue;");
> 
> Are you referring to that? Because that could be useful.

I'm saying let's make what you wrote work, instead of being a compiler error. Easiest way to accomplish this is to convert into a string.

-Steve
February 01, 2021
On 2/1/21 1:15 PM, Paul Backus wrote:
> On Monday, 1 February 2021 at 17:52:35 UTC, Adam D. Ruppe wrote:
>> On Monday, 1 February 2021 at 17:06:36 UTC, Paul Backus wrote:
>>> No, you've added an extra level of quoting by mistake.
>>
>> oh yeah, that's right.
>>
>> So we could prolly just define the stringof of interp to be slightly less crazy (the source version either being the proper fqn or the literal itself) and then there's no special case in mixin.
> 
> Well, you can't define .stringof in user code--at least, not in a way the compiler will recognize--so you'd have to make the interp literals into a new builtin type rather than a library template.

I kind of don't want:

mixin(i"int ${foo} = ${bar};");

to do something different than

mixin(i"int ${foo} = ${bar};".idup);

Because that would be utterly confusing. If stringof isn't going to produce the same output, the idup should be inserted.

idup should be CTFE able at all times (the one exception is floats, but that is a separate issue that needs solving regardless).

-Steve
February 01, 2021
On 1/31/2021 3:04 AM, claptrap wrote:
> Why is "working with printf" so important?

It's a canary. printf has a very simple interface, and if string interpolation doesn't work for simple cases, it is indicative of complexity problems.

Along with, of course, everybody uses printf and printf-style functions (dmd has many), and writef also uses a printf-style format.

I emphasize that #DIP1027 knows nothing about printf or its formats, other than having the default format be `%s`. The default can, of course, be overridden.

Again, DIP1027 KNOWS NOTHING ABOUT PRINTF OR ITS FORMATS.


February 02, 2021
On Tuesday, 2 February 2021 at 06:22:11 UTC, Walter Bright wrote:
> On 1/31/2021 3:04 AM, claptrap wrote:
>> Why is "working with printf" so important?
>
> It's a canary. printf has a very simple interface, and if string interpolation doesn't work for simple cases, it is indicative of complexity problems.
>
> Along with, of course, everybody uses printf and printf-style functions (dmd has many), and writef also uses a printf-style format.
>
> I emphasize that #DIP1027 knows nothing about printf or its formats, other than having the default format be `%s`. The default can, of course, be overridden.
>
> Again, DIP1027 KNOWS NOTHING ABOUT PRINTF OR ITS FORMATS.

Cheap solution: p"Blah blah {blah}" for printf style, i"xyz" for everything else?
February 02, 2021
On 2/1/21 12:52 PM, Adam D. Ruppe wrote:
> On Monday, 1 February 2021 at 17:06:36 UTC, Paul Backus wrote:
>> No, you've added an extra level of quoting by mistake.
> 
> oh yeah, that's right.
> 
> So we could prolly just define the stringof of interp to be slightly less crazy (the source version either being the proper fqn or the literal itself) and then there's no special case in mixin.

Thought: std.bitmanip.bitfields has some gnarly code that generates shifting and masking code for bitfields. It would be great to show how that code is vastly improved by the DIP.
February 02, 2021
On Tuesday, 2 February 2021 at 08:16:11 UTC, Max Haughton wrote:
> Cheap solution: p"Blah blah {blah}" for printf style, i"xyz" for everything else?

Or just a (zero runtime cost!) library function which is possible with the dip as-is. D excels at these things and there's no need to special case the compiler for it.

No more literal tokens will be added to this DIP. No qq"", no p"". It is all off the table.

The only major question I'm willing to entertain at this point is if the implicit string conversion is worth the cost. Everything else needs to be focused on getting the other little details right (like whatever it does with mixin)

BTW I have a 80% implementation up already (no implicit string impl and only i"" syntax added) so you can play with it yourself:

https://github.com/dlang/dmd/compare/master...adamdruppe:string_interp

The druntime components are

struct interp(string s) { string toString() const { return s; } }


And repeat for wstring and dstring if you like. Those must be in object.d for it to work.


For the demo, just use phobos' std.conv.text to convert it to a plain string (string s = i"anything".text;) or start writing your own functions to really explore the possibilities.