DIP 1027--String Interpolation--Final Review Discussion Thread

[Walter Bright]

On 2/4/2020 2:38 PM, Timon Gehr wrote:
> Personally, I think it is ridiculous that the DIP focuses on printf over all 
> other use cases so much yet in the common case, the proposed string 
> interpolation will lead to access violations when used with printf in the most 
> natural way, and it does not even support type safe formatting.

You seem to be arguing for both baked-in knowledge of printf format 
specifications, and against making it printf specific?

Replying not just to Timon here:

To clarify:

1. the DIP is not specific to printf, writef, or SQL formats. It has no 
knowledge of any of them. It isn't even specific to calling a function. It 
simply produces a tuple expression, the first of which is a format string 
constructed from user-specified (not builtin) formats.

The only exception is using %s if the user neglects to give a specification.


2. printf-aware checking can be added, but that would (and should) be an 
entirely orthogonal proposal, and would be effective with or without 
interpolated strings, as it has literally nothing to do with this DIP. A 
possible printf-format-checker would be run *after* the lowering to the tuple 
expression, and so would be equally effective for using or not using 
interpolated strings.


3. having the interpolator escape % by writing %% means that % becomes "baked 
in" as a special character. This is a completely unnecessary complication.


4. I repeat that I only use printf as an example because it is so well known and 
I don't have to spend a lot of time explaining what printf is and how it works. 
Note that writefln is also included as an example. There is nothing at all 
printf or writef specific in the design.


5. This proposal is not at all intended to be a substitute for knowing how 
printf formatting works. You're still going to have to remember to use %d for 
printing integers rather than %s or %g. This alone suggests that the DIP is not 
focused on printf.

----

The DIP is minimalist. This is intentional, as it proposes a very simple and 
straightforward rewrite of a literal into a tuple expression. Understanding 
tuple expressions (an existing D feature) is essential to understanding the DIP. 
This is a technique called "lowering" and is a great way of simplifying the 
semantics of a language and reducing corner cases and implementation bugs. Other 
examples:

1. the compiler rewrites 'while' loops into 'for' loops

2. the compiler rewrites RAII constructions into `try-finally` constructions

In fact, the compiler could profit from doing a lot more lowering transformations.