DIP 1027---String Interpolation---Format Assessment
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