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

[Paul Backus]

On Friday, 11 September 2020 at 16:32:28 UTC, Adam D. Ruppe wrote:
> Hitting all ten is impossible; some of them are directly 
> contradictory. But if we loosen some of those "should work" 
> things to "works with .idup", then we actually can do them all.

If that's your acceptance criterion, it seems to me like my, 
Walter's, and Jonathan's proposals are all just as good, since 
you can achieve the same result by appending `.text` and/or 
`.format`.

In fact, I'd argue that they're even better than DIP 1036, 
because they work with the existing `text` and `format` functions 
rather that requiring new a tailor-made overload of `idup` to be 
added to druntime.


> If we go up one level and just present the parameter list, then 
> you could still send it to an object, but you're no longer 
> forced to, so all that data is still available. Jonathan 
> Marler's original PR did what you proposed for `i""`. Walter 
> Bright's did.... almost... what you proposed for `f""`. But 
> better than any of them is Javascript's system, like I wrote 
> about in a previous message, adapted to D.

The main difference is that the Javascript system uses a 
regular-old Javascript list for its "spec object", rather than an 
opaque runtime-defined type. That's the real sticking point for 
me. Especially since the only features it actually buys you that 
you can't get easily with any of the naked-argument-list 
proposals are:

- Implicit conversion to const(char)*
- Ability to write custom overloads that supply a default format 
specifier

I don't think those two features alone are important enough to 
justify adding a bunch of extra cruft to Phobos and druntime--not 
to mention giving up compatibility with third-party libraries 
that *don't* add custom interpolation-spec overloads.