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

[Walter Bright]

#DIP1036

Full Disclosure: I am not favorably disposed to this, as it is fairly 
complicated and uses the GC.

 > It can bind to a parameter list, but it does not have a type by itself.

Makes no sense. What is it doing by "binding" to a parameter list? The examples 
make no sense, either, because assert doesn't have a parameter list.

 > idup

What does this function look like?

 > requires the GC

D needs to move away from such constructs.

 > interp and idup

Not clear when interp is called and when idup is called.

 > With proper library definitions, if usage of a string interpolation is an 
error, this DIP does not specify the language of the error condition. It is our 
preference that the resulting error of the idup call is emitted instead of the 
failed sequence match.

Finish this rather than hand wave.

 > functions which accept interp literals

what are "interp literals" ?

 > Because the type interp!"..." is not implicitly convertible to any other type

Why wouldn't it be?

 > This design is intentional to trigger the implicit idup call whenever it is 
used for conventional string-accepting functions.

I don't know how this might fit in with overload resolution.

 > "Best effort" functions

I don't know what the definition of "best effort" is when applied to a function.

 > What became clear as the prior version was reviewed was that the complexity 
of specifying format while transforming into a parameter sequence was not worth 
adding to the language.

I didn't think that was the conclusion. This DIP is much more complicated.

 > Because the interp template type will provide a toString member, it will pass 
properly to functions such as writeln or text and work as expected without any 
changes to the existing functions.

It won't work generally, however:

     void foo(string);
     struct S { string toString(); }
     void test() { S s; foo(s); }

fails.

 > To pass two sequential interpolation strings to a function that accepts 
interpolation strings, concatenation is not needed—separating the string 
literals by a comma will suffice.

This will have weird consequences for overloading, i.e. distinguishing one 
combined argument from two distinct arguments.

 > The complete specification of these translations is left up to the eventual 
implementors and language maintainers.

In my experience, doing the detail design of things often reveals a fatal flaw.

 > Compiler implementation

This section appears to confuse a definition of of the feature with its 
implementation. It really should be labeled "Overload Resolution".

I am totally confused why it refers to InterpolationString for matching 
purposes, and yet says InterpolationSequence and InterpolationLiteral are used 
for function overloading. Can't have it both ways.

 > with no further attempt to rewrite the sequence.

Does that mean there are multiple rewrites under other conditions?

 > In the case where it does not match, the InterpolationString will be 
rewritten as a call to a druntime library function named idup.

Does this imply a two-pass approach to overload resolutions? Try and fail, then 
try again with rewrites?

 > If multiple InterpolationString tokens are used in a parameter list, the call 
must match for the resulting expansion of all InterpolationString tokens, or the 
entire expression will fail to match.

Which expansion, as there are two different expansions?

What about variadic parameters? Lazy parameters?

No examples given of trivial and non-trivial overload matches illustrating each 
step of this process.

The reason I'm being pedantic on the overloading is we've done hand-wavy 
overload rules before (alias this, cough cough) and eventually found out it was 
unworkable.