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

[Dukc]

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 mean that this must be guaranteed to pass IMO:
>> 
>> [snip]
>
> No, that will not pass, and is guaranteed not to pass. 
> typeof(interpolation) is string.
>
> Just like this wouldn't pass:
>
> auto x = 1, 2;
>
> int foo(int, int);
>
> foo(x);
>
> The compiler wouldn't allow it, and would rewrite with idup, 
> yielding a string.

You need to specify the rules about the behaviour of the 
expression unambiguously, and that is going to be a lot harder if 
you don't allow yourself the luxury of using a primary type.

If I understood what you're proposing, the expanded form is 
attempted only when the interpolated string is an argument to a 
function or a template. But this still leaves a lot of questions:

1: Is the expanded form attempted inside constructors?
2: Is the expanded form attempted if the interpolated string is 
passed as first argument in UFCS style?
3: What a variable with `enum` storage class stores an 
interpolated string and that gets passed to a function?
4: What does this template do when called with interpolated 
string? `auto foo(T...)(T arg){bar(arg);}`
5: If an interpolated string gets called by an operator, what 
happens?
6: Probably much more issues like these.

>> I don't think it's that bad, we tend to do stuff like 
>> `writeln("hello, " ~ name)` anyway. Relatively small 
>> inefficiencies like this don't matter in non-critical places, 
>> and critical places need to be benchmarked and optimized 
>> anyway.
>
> I don't consider it a small inefficiency to involve all of the 
> machinery of generating a string just to throw it away after 
> printing.
>
> But in any case, it's unnecessary without good reason.

The reason would be to have an unambiguous type for the string 
literal. I'd much rather have inefficiencies like the one 
mentioned, that I can manually optimise away if needed, than 
complex language rules that are likely to result in 
implementation bugs.