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

[Steven Schveighoffer]

On 9/11/20 1:13 PM, burt wrote:
> I think that, in principle, the way that is described by the DIP is the 
> best way for i"" strings to work. However, I still have some points:

Thanks. We are most certainly evolving on what we think is best, based 
on feedback here and internal discussions. I hate to leave this feedback 
hanging, even though likely the DIP as is will be moot once we update. 
However I will respond to the points you made in the context of the 
current DIP text.

> 
> * The DIP says the name of the interpolation spec template defined in 
> DRuntime is unspecified, but then does specify a name for 
> `isInterpolationSpec`. Is this even necessary? I think that name should 
> remain unspecified as well.

As a function which accepts parameters, you need some way to determine 
whether you have an interpolation spec. If we don't name the type or 
template, you can't specify the type to accept. So you need some way to 
determine that you got one. Doing it this way leaves more discretion to 
the implementation.

> * The DIP tries to explain the implementation of `toFormatString` and 
> `hasAllSpecs` in great depth. But is this even necessary? It seems to me 
> that this should actually be an optional mechanic (like `idup`) that is 
> implemented by DRuntime as a convenience function, and those sections 
> can be removed entirely, which will also simplify the DIP, or can be 
> moved to an "optional mechanics" section.

In the current DIP text, toFormatString is the only official way to 
fetch the spec text.

hasAllSpecs is really just a mechanism to enable the implicit conversion 
to const char *. I'm not sure we had to allow access to it.

> 
> * The addition of an optional `alias this` implicit conversion only if 
> all the format specifiers are defined seems way too complicated for me. 
> My preference would be to add an implementation-defined function (just 
> like `idup` now) to the template, so users of `printf` can just write:
> ```d
> printf(i"${%d}a + ${%d}b = ${%d}(a + b)".toFormatz());
> ```
> or something.

This won't work, because you need to translate just the format 
specifier, and your proposed form must pass through all the parameters. 
This *might* work, if you use a template, but it's getting to the point 
where it's really not worth it.

> Alternatively, it's not that hard to write a wrapper 
> around `printf` which overloads for interpolated strings, but an 
> implicit conversion tailored for immutable(char)* seems excessive.

The goal was to keep the ability from DIP 1027 to be able to call printf 
(and other C format + varargs functions) without modifications. However, 
we agree with you (and most other commenters here) that this requirement 
does not hold its own weight, and too much complexity was added for this 
one possibility.

> 
> * The grammar changes have some issues: "Expression" is defined, but 
> this name already exists at 
> https://dlang.org/spec/grammar.html#expressions. So, it should be given 
> its own name.

There are more than just this one problem in the grammar (I have found 
another which nobody has pointed out yet). Admittedly, both Adam and I 
are not grammar experts, and we basically copied what Walter had written 
in DIP1027.

> 
> * I feel like interpolated strings should work out of the box together 
> with `mixin` without requiring a DRuntime CTFE `.idup` call.

It would be nice (along with any other usage that binds directly to a 
string). We think we have this issue solved with the next DIP iteration.

> 
> * As a personal matter, the i"" q{$a + $b} implicit concatenation magic 
> seems weird. My advice would be to just add `iq{$a + $b}`.

We also agree with this. Again, the next version should help here. This 
also was a holdover from DIP1027.

> (* As a minor point, some code blocks don't have the language set to D, 
> which would improve readability.)
> 

Thanks, I will make sure the code blocks are properly annotated (Mike 
actually did a lot of them as an editing review).

-Steve