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

Walter Bright newshound2 at digitalmars.com
Mon Feb 24 22:11:08 UTC 2020

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.

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

> How is this an AST macro, but (string-literal, apples, bananas) not?

Because its behavior is defined by a template, not 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".

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.

Operator overloading is for user defined types, not builtin types.


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.

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.

More information about the Digitalmars-d-announce mailing list