Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2

[Walter Bright]

On 1/29/2021 7:06 AM, Steven Schveighoffer wrote:
> The point of this is, we don't want to fit into printf-style formatting,

That is abundantly clear :-)

But it is a test on how powerful the feature is and where its limits are.


> DIP1027's syntax is designed to fit with a few existing functions.

More accurately, it is designed to fit with an enormous amount of existing use. 
The printf format pattern is very common with other functions - dmd's source 
code has many examples of it.

DIP1027 actually had zero knowledge of printf formatting other than %s being the 
default format, which is shared with writefln. This was very intentional in its 
design.


> It puts the 
> burden on the user to make sure they understand how the rewrite will happen, and 
> which functions to use to do this.

The rewrite is far simpler than #DIP1036's is, and no functions are used to do 
it. Note how short DIP1027 is.


> It is not forgiving of mistakes, which will 
> compile and do the wrong thing.

Since D now does printf format checking, format mistakes will no longer compile. 
(We should have added that to D a decade ago! Dang I like that feature.)


> But I don't want to rehash DIP1027 here, that discussion has already happened.

Since #DIP1027 was rejected, it is necessary for #DIP1036 to be a substantial 
improvement over it, otherwise we just go sideways. Comparisons are fair.


> If you want to compare the two briefly, I would say DIP1027 designed for writef 
> and format, nothing else. It can be used unintuitively with printf and other 
> functions that have some similar parameter layouts. It can be used accidentally 
> with many functions that happen to accept the parameters as arranged.

You and I strongly disagree on that assessment.


> DIP1036 is 
> designed to be used by library writers to provide a mechanism to distinguish and 
> handle properly interpolation strings ONLY when intended,

The fallback to matching string parameters doesn't fit that, and isn't different 
from DIP1027 in that regard.


> and do it with little 
> effort, all while also providing the user a mechanism to seamlessly convert 
> normal data into string data.

It pains me to say this, but would I use #DIP1036 in my own code? No. It adds 
too many layers of abstraction, is hard to document, hard to remember, adds 
special new rules for overloading, is unclear when it uses the GC, I have to 
write wrappers to use it, and the user-facing part just doesn't look good.

DIP1027 was a simple lexical rewrite - easy to remember, easy to document, 
sensible defaults, no allocations, no function calls, no overloading, no 
wrappers. It wasn't perfect, but simplicity and predictability are huge advantages.

P.S. I used to write macros in C named "printf" that would muck about with the 
arguments, add some logic, then call the real printf. After a few years I got 
tired of them, and put them in a bag with some rocks and threw it in the swamp.