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

[Meta]

On Wednesday, 3 February 2021 at 16:52:23 UTC, Q. Schroll wrote:
> Getting a string is probably what most users expect most of the 
> time. Handling the secondary type must be explicit. It is 
> almost an implementation detail that shouldn't be exposed to 
> the user too easily.
>
> (I'll post that to the feedback thread as well.)

I 100% agree with this. Reading over the thread, it seems clear 
that we're trying to pessimize the most common use case to make 
@system @nogc usage possible... but this is counter to D's design 
philosophy of doing the correct/convenient thing by default, but 
also enabling more advanced use cases, potentially with a bit 
more effort. I think this is the way we should go.

"istrings" (i"", iq{}, i``, etc.) should by default create a 
GC-managed string literal. This is by far the most intuitive and 
easy to understand thing to do, and if you're using istrings for 
code generation, you don't care that it's allocating memory.

However, if you want a tuple sequence as described in the DIP, 
you can simply call a (probably compiler-supplied) helper method; 
maybe it doesn't even have to be new: why not .tupleof?

auto apples = 2;
auto bananas = 3;

auto s1 = i"I have ${apples + bananas} fruit";
static assert(is(typeof(s1) == string));

auto s2 = i"I have ${apples + bananas} fruit".tupleof;

Then we can hide all the complexity of interpolated sequences 
behind the .tupleof (or whatever we decide on) magic property.