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

[James Lu]

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.