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

[Steven Schveighoffer]

On 2/24/20 4:10 PM, Walter Bright wrote:
> On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
>> How can you possibly arrive at this conclusion? We lower to templates 
>> all the time.
> 
> The language is nowhere defined as lowering to specific templates. There 
> are indeed some lowerings to templates in the implementation of the 
> language, but those are NOT user defined templates, they are simply an 
> implementation convenience.

typeid expressions lower to a TypeInfo object. That is a specific named 
object in object.d.

All we're saying is that it lowers to a specified type in object.d.

>> By this definition all operator overloading in D is AST macros.
> 
> Operator overloading is not supported for basic types. It's 
> fundamentally different from what was proposed for interpolated strings.

Not at all. In fact, operator overloading lowers to a specific template 
on that type, which allows the user to write whatever code they want. 
This is how lowering works.

Our proposal is even more restrictive, as the template and its API are 
actually defined by the language.

>> Except that's not what's happening here. It's lowering to a template 
>> defined by the language, not the user. The user creates their own API 
>> (not language) by accepting such a template and unsurprisingly can 
>> react differently to different parameters to said function or template.
> 
> "creates their own API" => AST macros

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?

>> If you have an example that proves me wrong, I'd love to see it. How 
>> can this feature do something that is "like AST macros"?
> 
> Because the proposed templates modify the behavior of basic types. From 
> the discussion:
> 
>  > i"$apples and ${%d}bananas"
>  > =>
>  > (__d_format_literal!(Format.init, " and ", Format("%d")),
>   apples, bananas)

Where is the basic type modification here? i"..." is not a basic type, 
it's a string interpolation. It's never been in the language before. It 
doesn't translate into any basic type, it translates into a compile-time 
list of expressions.

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

---

Probably this is being misunderstood. Let me rephrase the proposal. 
Let's assume we agree on the format string grammar that was presented in 
the DIP:

i"$apples and $%{d}bananas" will be transformed into:

(interpolation_spec, apples, bananas)

Where interpolation spec will be an instance of a language-defined type. 
It will have the following API:

1. spec.formatString!(s) where s is a string, will be a compile-time 
constant format string (guaranteed to end in a null character) where all 
the interpolated expressions are handled as follows:
   a. If an interpolation expression is preceded with {x}, where x is 
the string literal in the braces, the entire interpolation expression 
will be replaced with the string literal x.
   b. If an interpolation expression is not preceded with {...}, then 
the entire interpolation expression will be replaced with the string `s` 
passed into the formatString member template.

2. spec.formatStringZ() will return the equivalent of 
`formatString!("%s").ptr`.
3. If all interpolations are determined to have a {...} specifier, then 
the interpolation_spec can be implicitly converted to a null-terminated 
const(char)*.

4. There will be an isInterpolationSpec(T) template added to object.d 
which will return true if the parameter T is an interpolation spec type.

---

That's it. The whole definition of the template and whatever is simply 
implementation details.

-Steve