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

[Adam D. Ruppe]

On Friday, 11 September 2020 at 10:43:54 UTC, Paul Backus wrote:
> Anyway, I don't expect my idea to satisfy everyone equally.

This right here is why the idup mechanism is how it is.

There's ten cases we identified from various people to try to hit:

  1. string s = i""; should work.
  2. @nogc use of i"" should be possible.
  3. foo(i""); should work where it is foo(string) {}
  4. for createWindow(string s, int width = 0, int height = 0), 
calling createWindow(i"Connected $id") should NOT result in 
createWindow("Connected %s", id). It should either error, or 
convert the entire expression to a string.
  5. db.query(i""); should be possibly to do safely
  6. int x; verbose_debug!(i"$x assertion failed"); should be 
possible
  7. readf(i"$foo"); should be possible as well as other ref, 
scope, etc. types
  8. compile-time checking of format strings should be possible
  9. mixin(i"T $name;"); should work
10. printf(i""); should work


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.

C# style objects (which I advocated for first btw) cannot 
possibly do numbers 6, 7. Putting the arguments in an object 
forces evaluation, which would trigger CTFE errors on 6 and 
discards the ref storage class in case 7. (now I'm kinda of the 
opinion that case 7 is silly and not worth fussing over. But the 
general problem with it is once you put it in an object, parts 
are lost. I know a lot of people feel the whole concept of D's 
storage classes were a mistake, but it is what it is.

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.

(and I know some of this should be in the DIP, to be honest, I've 
just written it up a couple times and over the delay to formalize 
the process, I just plain forgot what I said where. I *very* much 
simply prefer working with code and casual conversation than with 
this passive voice hyperformal waterfall spec speak. The dip text 
itself got weakened too by the focus on specifying ToFormatSpec 
instead of the actual structure implementation. It is the same 
code... just rewriting it in formal spec-talk instead of 
straightforward code is painful. I dropped out of college!)