Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Andrei Alexandrescu]

On 9/12/20 10:37 AM, James Lu wrote:
> On Saturday, 12 September 2020 at 02:48:38 UTC, Adam D. Ruppe wrote:
>> On Friday, 11 September 2020 at 20:46:05 UTC, Paul Backus wrote:
>>> This solves the issue of accidentally passing the wrong thing with 
>>> i"Window $id", and also prevents non-interpolation-related accidental 
>>> usage, like mixing up the width and height.
>>
>> yeah that's legit.
>>
>>
>> So what we're considering is simplifying it a bit and dropping the 
>> embeddable format strings. Also Steven is seeing if he can make 
>> auto-conversion work and I'm mulling over your idea of two different 
>> prefixes. t"..." yields the tuple, i"..." automatically calls idup (or 
>> whatever). t is the building block, i is the "just give me a string" 
>> shortcut built on top of t.
>>
>> So in my next draft, processing a t"" yourself looks like:
>>
>> auto foo(InterpList, Args...)(InterpList interp, Args args) {
>>     string ret;
>>     foreach(idx, arg; args) {
>>         ret ~= interp.strings[idx];
>>         ret ~= to!string(arg);
>>     }
>>     ret ~= interp.strings[args.length];
>>     return ret;
>> }
>>
>> And processing an i"" is trivial; it is just either a string or a 
>> subclass of string (aka a struct with alias toString this) and you'd 
>> just use it like that.
>>
>> The t"" is more composable; it is the superior language feature. But I 
>> can live with a convenience compromise.
>>
>> So we'll see.
> 
> Too many features, too much syntax, increases mental overhead. Instead 
> of adding syntax, you can use an existing language feature to do it. For 
> example, t"" could be the default, and it can use alias this to do an 
> automatic conversion of t"" to i"":
> 
> struct Tuple {
>      private string toString();
>      alias toString this;
> };
> 
> I don't know how using alias this in this way would change compilation 
> time to  relatively efficient (=efficient enough to test with) machine 
> code.

I think it's telling that now it's not only about adding two new tokens 
to the language, but about a synthetic subtyping relationship between 
them. How can this pass the laughing test?