February 02, 2021 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to claptrap | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 Re: Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Max Haughton | 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. |
Copyright © 1999-2021 by the D Language Foundation