Feedback Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2

Adam D. Ruppe destructionator at gmail.com
Wed Feb 3 18:17:03 UTC 2021


On Wednesday, 3 February 2021 at 17:47:19 UTC, Q. Schroll wrote:
> Akin to `staticArray`, Phobos can (should) supply a template 
> `asInterp` that forces a i"..." literal to be statically typed 
> as a tuple around the respective `interp` sequence.

Something to keep in mind is that tuples cannot actually be 
wrapped in D. As soon as they are anything other than slices of 
themselves or directly used as function parameters, they start 
losing information.

>     auto asInterp(string str, Args...)(interp!str first, Args 
> rest)
>     {
>         import std.typecons : tuple;
>         return tuple(first, rest);
>     }

Like here, if there was any refness in rest, it is gone in the 
return value. If it was used as a template argument and had alias 
parameters, that information is lost.

That's the big driver toward the naked tuple - it is just the 
*only* way to express all the possibilities D has to offer.


Conceptually, dip 1036 is trying to express i"foo" becoming:

struct Interpolated(Pieces...) {
     Pieces... pieces;
     string toString() { return text(pieces); }

     alias toString this;
     alias args this;
}

That is, a new type with two different implicit conversions 
depending on appropriate context.

But the fact is that's flat-out impossible to today's D, so the 
dip makes some compromises to get as close as it can with the 
simple naked tuple on one hand and the implicit conversion rules 
specified on the other.

> Getting a string is probably what most users expect most of the 
> time, even in templates.

That's why the implicit conversion part is in the dip, but your 
point about the static arrays is an interesting alternative 
approach.


BTW this part of the argument barely matters to me. I will 
probably *never* use the implicit to string thing since it is 
hard for me to think of a situation where actually passing the 
tuple to the function isn't a better approach.


More information about the Digitalmars-d mailing list