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

[Steven Schveighoffer]

On 1/29/21 5:39 PM, Dukc wrote:
> On Friday, 29 January 2021 at 19:10:55 UTC, Steven Schveighoffer wrote:
>> On 1/29/21 7:58 AM, Dukc wrote:
>>> A string literal is a string that is implicitly assignable to the 
>>> other alternatives via value range propagation mechanics, or that's 
>>> how I understand it at least.
>>
>> No, this isn't range-value propagation. There is no way to recreate or 
>> save the type that is a string literal.
> 
> It may be that VRP is not the correct term, but I meant that a string 
> literal (just like an array literal, or VRPed integers) has one 
> unambiguous primary type, that is used if it's not immediately assigned 
> to something else.
> 
>> D has, however, added things like typeof(null), which still work as 
>> polysemous values (assignable to multiple types).
> 
> But even there: it has a primary type that is tried first, before any 
> conversion rules kick in. Unlike what you're proposing.

I think we're going to end up with something like this. The more I think 
about it, the more I feel that having a primary type be the tuple is 
required.

When I wrote that typeof(i"...") is string, that bothered me, even 
though it's how I had pictured it. The thing that is really bad is:

pragma(msg, typeof(i"hello, ${name}")); // string
void foo(T...)(T args) { pragma(msg, T); }
foo(i"hello, ${name}"); // tuple(...)

This just can't work that way. It reminds me of autodecoding where 
hasLength!string is false, yet string.length works.

I think the idup rewrite is still viable, just not as seamless (e.g. if 
the tuple has a type, then auto x = i"..." will not be a string as 
outlined in the DIP). Adam is trying to set up an implementation to play 
with, where we can see if it's viable.

-Steve