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

[Steven Schveighoffer]

On 2/24/20 5:11 PM, Walter Bright wrote:
> On 2/24/2020 1:45 PM, Steven Schveighoffer wrote:
>> Our proposal is even more restrictive, as the template and its API are 
>> actually defined by the language.
> 
> API is defined by the language, but not the behavior.

The language doesn't define my function's API, I do. I get to decide the 
types of my parameters, which ones are accepted, which ones aren't, what 
the names of my functions are, etc. Maybe you mean ABI?

> 
> 
>> No. It's overloading, not AST macros. How can an overload affect the 
>> AST other than to generate code specific to the type being accepted?
> 
> "generate code" is how.

This generates code (and AST):

int foo()
{
   return 1;
}

You can see it from the disassembly that a return statement is 
"generated". That's what I meant.

> 
> 
>> How is this an AST macro, but (string-literal, apples, bananas) not?
> 
> Because its behavior is defined by a template, not the language spec.

Not true. Both are defined by the language spec.

> 
>> That's it. The whole definition of the template and whatever is simply 
>> implementation details.
> 
> No, it isn't. It's leaving things up to templates like "formatString".

The result of formatString is defined by the spec. It doesn't matter how 
the template actually generates it. The fact that there's a template 
involved has no bearing on what the result should be (which will be 100% 
defined as I said).

> There are other instances of the compiler lowering things to templates, 
> but the behavior is still defined by the language, not the template. The 
> templates were not strictly necessary, they were just a convenience.

As is the case here.

> 
> The semantics of an interpolated string must be defined by the DIP, not 
> deferred to some template. If the implementation of those defined 
> language features is done by a template, that is an implementation 
> choice, not part of the DIP or spec.

This is exactly how the proposal is defined. There is no wiggle room for 
the template (or whatever we decide) to do anything but follow the spec 
exactly. You will never get alternative behavior from that type.


> 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.

You can have foo(double) and foo(float), and foo(1.0) will result in 
something different than foo(1.0f).

-Steve