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

Steven Schveighoffer schveiguy at gmail.com
Mon Feb 8 14:24:35 UTC 2021

On 2/8/21 6:46 AM, FeepingCreature wrote:
> On Thursday, 4 February 2021 at 16:15:03 UTC, Meta wrote:
>> 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.
> IMO, if I pass an i"I have ${apples + bananas} fruit" to a function, and 
> it allocates memory, this feature completely misses its purpose and I 
> can't see where I'd use it. Right now, we're using a *lot* of format 
> calls of the form `template function!"format string"(arguments), and the 
> fact that these calls are high-performance and don't involve the GC is a 
> massive argument in their favor. In extreme cases we can end up pushing 
> megabytes of data every second through functions like this. Demanding 
> tupleof for every such call is such an awkward syntax that I'd honestly 
> rather not use the feature at all.

I would also not use a feature where .tupleof or some other syntax is 
needed to do what is needed (in major use cases). The goal here is to 
simplify syntax, we already have the comma-quote-spam form. However, I 
do like the mechanism of .tupleof for explicitly requesting the tuple 
form where it makes sense.

So an important part of this DIP that will NOT change is that you should 
be able to accept the tuple form via overload without having to tack on 
a converter or property.

> To me the tuple form is the primary usecase, not the string form. I 
> understand that people think developers want something simple first and 
> foremost, but if the complex form is the *only form I'd be interested in 
> using*, then something's wrong.

I think we can have both use cases, with overloads declaring somehow 
they accept the tuple form, and have it usable as a string form in other 

For sure, the primary use case for me is the tuple form. But there have 
been several users who are heavy users of the D language that have also 
declared that their primary use case is the string form (and in some 
cases have said they will NEVER use the tuple form).

If we don't have both available, the feature feels incomplete. My goal 
is to have both. And I think we can have both. I think this DIP as 
written covers both. The tricky part is, what is the *default* for 
functions that accept tuples but are not written to accept the tuple 
form. That is where a complete confusion would happen. And I am in 
agreement with people here that having the thing change forms when 
called on a variadic template, while workable, is not ideal.

So I think the next update, we will have a more definite mechanism to 
accept the tuple form without user intervention, and a more solid rule 
for when the idup rewrite happens.

This review is almost done, and it looks likely a 3rd review will have 
to happen if I make significant changes. But this is what these reviews 
are for. I'll post another thread when I put up the PR for the next 
changes and we can discuss there.


More information about the Digitalmars-d mailing list