Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Steven Schveighoffer]

On 9/9/20 4:12 AM, WebFreak001 wrote:
> On Tuesday, 8 September 2020 at 10:59:31 UTC, Mike Parker wrote:
>> [...]
> 
> I think it's a little bit awkward and risky that things like
> 
> foo(Args...)(string a, Args args)
> or I suppose also
> foo(string a, int b)
> 
> will get more than one parameter with a call like
> 
> foo(i"hello $i");

That won't compile. The interpolation spec type will not implicitly 
convert to string.

> 
> which is very counter-intuitive to all existing concepts (this is a case 
> that would pass multiple arguments from something which looks just like 
> one single string)
> 
> For example the SQL example shows very nicely why doing this without the 
> library author allowing it is a bad idea. You argue that an attribute 
> for the entire interpolated type is a bad idea and I agree with that, 
> however an attribute just for allowing the compiler to expand 
> interpolated strings to multiple arguments like this would be a great 
> way to avoid unintended potentially dangerous usage.

The intention is that you have to opt-in by specifying a template 
parameter that accepts the spec. An attribute is not necessary.

> 
> I really like the idea of the special _d_interpolated_string type 
> containing all the parts as that will make usage very flexible. However 
> I really dislike the intended API usage with `toFormatString` and 
> `hasAllSpecs`. To me it seems very specialized just for the printf 
> function and not really designed to be usable for functions performing 
> simple concatenation like text(), which I think are a more common use. 
> It looks like directly accessing "Parts" was not intended, but direct 
> access would be the only way to reasonably and efficiently implement 
> string interpolation as a user (without doing error-prone string replace 
> operations which would break as soon as a user manually types in a % 
> character)
> 
> Instead of forcing the % syntax onto users using toFormatString, can we 
> specify a proper API that could be implemented without it breaking with 
> a simple
> 
> i"You scored 100% with $points!".idup

You are right in all of this. I think we probably need to allow access 
to the parts, and this solves a lot of issues. We can leave everything 
else, including printf compatibility.

One of the goals of this mechanism is to start simple and expand if 
necessary. But it's going to be impossible to prevent people from 
introspecting the template parameters anyway. Just providing an alias to 
the parts is a simple thing, and allows much better code.

One thing that I cringe on is the SQL example, where each parameter 
needs a number. With access to the parts, this is a single pass. With 
only toFormatString to get the format string, you have to put in a 
searchable placeholder in the format string, and then replace that on a 
second pass.

I will talk with Adam and Mike and see how to proceed, as this requires 
a bit more work.

-Steve