Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1
schveiguy at gmail.com
Wed Sep 9 12:40:41 UTC 2020
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 %
> 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
I will talk with Adam and Mike and see how to proceed, as this requires
a bit more work.
More information about the Digitalmars-d