DIP 1027--String Interpolation--Final Review Feedback Thread

[Walter Bright]

On 2/2/2020 7:06 PM, Adam D. Ruppe wrote:
>> Mixing Conventional Format Arguments With Interpolated Strings
> 
> This DIP proposes leaving all % unmodified in the string, yet it also injects % 
> characters into the string. This is a mistake - it forces user code to be aware 
> of implementation details and carefully encode all special characters. Web 
> programmers learned the hard way the problems of sloppy encoding.

A % is injected only in the case of $Argument where %s is injected. This is the 
default format. If other formats are desired, ${FormatString} is the syntax. If 
the user wants a %% in the rest of the string, he can add it. The user is 
expected to know what the intended target of the format string is and cater to it.


> As it stands, consuming functions have no way to tell if the first %s from `i"%s 
> $foo"` is meant to go with the subsequent argument `foo` or the latter; it will 
> throw off all future processing.
>
> The DIP must be amended to specify that ALL % characters in the i"" string are 
> replaced with %% in the yielded string.

This is entirely up to the user to use %% where appropriate. Your proposed 
change will inadvertently wed it to the printf format.


>> W and D Interpolated Strings
> 
> should work, the DIP rationale is poor. This is an arbitrary limitation and 
> inconsistency with the rest of the language.

I doubt anyone would use it. We can always add it later if desired, but removing 
it would be painful. It's not optimal to add features unless there is a clear 
and present need for it.

The original specification carefully treated the various string encodings 
equally. But as 20 years have passed, it's become very clear that UTF-8 is the 
hands-down winner and the W and D formats are aberrations.


>> [not present]
> 
> The DIP fails to address the feedback from the previous review round on concerns 
> for overloading functions to use the new feature.
> 
> I move that we amend it so the format string literal is not created directly, 
> but instead wrap it in `_d_interpolated_string!"..."` instantiation.
> 
> So
> 
> writefln(i"foo % $bar")
> 
> is rewritten to
> 
> writefln(_d_interpolated_string!"foo %% %s", bar);
> 
> This allows a library implementation to detect it for the purposes of function 
> overloading with zero other loss relative to the DIP status quo (in fact, the 
> template there could be defined to reduce to the literal exactly via an 
> eponymous enum).

I don't see a point to overloading beyond what the tuple elements provide. 
There's a lot of value in having straightforward semantics - having a hidden 
template do something unexpected with overloading is hard to justify.


> This is different than the function call mentioned at the end of the DIP by the 
> review manager, which lowered it, format string and all in to a function call. 
> Here (a proposal that came up in the original thread), only the format string 
> gets the template call, avoiding the other difficulties brought up with the 
> function call.