DIP 1027---String Interpolation---Format Assessment

[Steven Schveighoffer]

On 2/25/20 1:54 AM, Walter Bright wrote:
> On 2/24/2020 2:45 PM, Steven Schveighoffer wrote:
>>> My inference of the discussion about this in the n.g. was the 
>>> templates would be used so users could customize the behavior to be 
>>> whatever they wanted.
>> By accepting a different type from string. In other words, an overload.
>> This means you can have code that treats an interpolated string 
>> differently than a string. Overloads based on literal types are not a 
>> new feature.
> 
> Were you proposing that an i"xxxx" be a different type? (DIP 1027 did 
> not assign a type to it at all.)

No, I proposed that the first element of the tuple be specified as a new 
spec-defined type instead of a string.

I would love to have there be a way to specify that it's a specialized 
type that is akin to string literals. I'm not qualified to do that, and 
I'm not sure it's something we want to do (this WOULD be extra 
complicated and require some compiler magic).

I would note that it seems uncharacteristic for string enums to not be 
equivalent to string literals. If that were the case, this type WOULD be 
easy to set up effectively as a string literal.

Having the type detailed in the spec and implemented in the library is a 
"low cost" solution. Effectively, even though it doesn't need to be 
specified how this works, the compiler-library interaction is done via 
simple lowering, and the existing compiler has all the tools to 
implement the new type already.

> This would be radically different from 
> DIP 1027, and a large increase in complexity (adding any new basic types 
> is a big deal and a very intrusive change, and is tough to justify).

It's not a basic type in terms of a type defined by the compiler, but a 
type defined by the spec and implemented in the library (with existing 
language mechanisms). It's not intrusive at all, the changes to your 
proposed DIP are minimal, as it's still lowering.

> 
> This is different enough from DIP 1027 that it would merit a separate DIP.

Adam is working on this: https://github.com/dlang/DIPs/pull/186

> DIPs for the core language specify only behaviors, not implementations. 
> Implementation possibilities can be included in an advisory manner only. 
> Note that nowhere in the (massive and complicated) C++ core language 
> specification is there any description of how the compiler should be 
> implemented. Writing that an implementation must refer to specific 
> templates implies that the behavior is customizable by the user via 
> modifying those templates.

I understand, and I think we can reword the DIP proposal to reflect that.

-Steve