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

[WebFreak001]

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");

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.

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

?