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

[Walter Bright]

On 2/3/2020 7:48 AM, Steven Schveighoffer wrote:
> I propose an incremental change to this DIP.
> 
> Instead of
> 
>      i"a, $b, ${%d}c"
> 
> lowering to the tuple
> 
>      ("a, %s, %d", b, c)
> 
> it lowers instead to the tuple
> 
>      (__d_interpString!("a, ", __d_formatItem.init, ", ", __d_formatItem("%d")), 
> b, c)
> 
> The item returned from __d_interpString shall be defined by the library, but one 
> that implicitly converts to a string or immutable(char)*, with the string 
> contents being identical to the current DIP's format string. It also will 
> provide access to the original sequence as parsed.
> 
> __d_formatItem should be essentially a typedef of string, with a default value 
> of "%s".
> 
> The rationale for this change is twofold:
> 
> 1. Providing an alternative type that decays to a simple string allows 
> specialized handling of such an interpolation via overloading. Some current 
> problems that can be alleviated by this (as identified in the DIP discussion):
> 
>     a. multiple interpolated strings as parameters to writefln. e.g.: 
> writefln(i" ... $a ... ", i" ... $b ... ") can be handled.

No rationale is given why this needs to be supported at all. Note that the user 
can always write:

   writefln(i" ... $a ... ");
   writefln(i" ... $b ... ");


>     b. Escaping of "%" characters in formatted strings. e.g.: 
> writefln(i"$percentage% complete") will assume the "% c" is a format specifier, 
> but could be overloaded to ignore that '%' if it knows the format string came 
> from an interpolated string.

The user can write writefln(i"$percentage%% complete") as required. Baking % 
into the specification with special escapes completely weds it to printf/writef 
formatting, which is carefully avoided (at your request!).


>     c. alternative default format specifiers. For example MySQL uses only the 
> '?' specifier for parameters, so one must prefix EVERY string interpolation 
> parameter with ${?}. If a function overload knows you are using string 
> interpolation, it can generate a proper SQL query without needing those prefixes.

I understand the appeal of this. But it's the same thing as AST macros. It's 
having the language semantics defined by a hidden template (which happens 
nowhere else in D). It's undeniably powerful, but way too powerful and not the 
right path for D.


> 2. The compiler is already doing the work of splitting up the parameters and 
> string data. If the format string is simply passed as a string, then determining 
> the original parsed form (of string + format specifiers) is difficult, if not 
> impossible, and definitely unnecessary if the compiler has already done it.

There's no need to revert it. The D compiler does such "lowering" to simpler 
forms in many places already.