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

[Walter Bright]

On 2/2/2020 1:47 PM, Jon Degenhardt wrote:
> * Better separation of language level specification and the implementation.
> 
> It would be easier to read and evaluate the DIP if the language level constructs 
> available to the programmer were better separated from the implementation. This 
> is done to some degree in the DIP, but in a several places the writing mixes the 
> language level proposal and the anticipated implementation.
> 
> One of the clearer examples is the first line of the Concatenations section. 
> This describes the behavior when an interpolated string is concatenated with a 
> literal string. However, it also describes which compiler parsing pass this 
> occurs in. This places responsibility on the DIP reader to identify if the 
> implementation specific called out has an impact on the language feature as seen 
> by the programmer. (If it does, it is not called out in the DIP.)
> 
> The above example is rather minor. The larger one involves the notion of the 
> rewriting interpolated string to a tuple. From the wording used in the DIP, this 
> appears to be primarily an implementation approach to achieve the desired 
> functional goal. But whether this is the case or not is not clear. Is the tuple 
> a first class object visible to the programmer? Or, is the implementation free 
> to throw away the tuple implementation if an alternate way to achieve the 
> functionality is identified?

The introduction to the D language specification starts with the "Phases of 
Compilation". Identifying how the string interpolation fits in with this is 
appropriate and aids in understanding the proposal.

https://dlang.org/spec/intro.html


> * Incorporate the rationale for specific decisions listed in the Review Round 1 
> feedback in the body of the DIP.
> 
> In particular, the rationale for "no assignment to string" should be 
> incorporated into the body of the DIP, and the more general goals of BetterC 
> compatibility and no GC allocations. These are important considerations and 
> would be better described in the main body of DIP.

As long as the information is present, it doesn't really matter what part of the 
DIP it is in. It'll get redone for incorporation into the specification anyway.


> * The family of functions string interpolation can be used with should be 
> clarified.
> 
> The DIP provides examples of using interpolated strings with 'writefln' and 
> 'printf'. However, it is not clear from the writing whether these are examples 
> or an exhaustive list.
> 
> A DIP reader assuming examples would likely assume interpolated strings can be 
> used with a wider variety of string formatting functions, for example, 
> 'formattedWrite', 'format', and 'sformat'. A reader assuming an exhaustive list 
> would draw very different conclusions.
> 
> The correct interpretation is not clear from the written text. A correct 
> interpretation is important to assessing the value of the DIP, and the writing 
> would be better if this was explicit.

There is nothing in the discussion of how it works that implies it is tied to 
any particular function. 'printf' and 'writefln' were selected for examples 
simply because they were so well known that no further explanation of them was 
necessary. Also, 'printf' and 'writefln' are not magic functions specially known 
and handled by the compiler, and there's no hint in the DIP that this situation 
is being changed.

> * Clarify whether interpolated strings can be declared/manipulated outside the 
> context of a format function literal arguments.
> 
> For example, is the following valid?
> 
> void foo()
> {
>      auto numApples = 3;
>      auto interpolated = i"$numApples apples";
>      writefln(interpolated);
> }
> 
> This type of usage would be expected by many programmers. However, there are no 
> examples of this usage in the DIP, and several of the goals of the DIP imply 
> this would not be allowed. With the current writing the DIP reader must infer 
> whether this is allowed or not. The DIP writing would be improved if this topic 
> was explicitly addressed.

The behavior is clear if the text is followed. `interpolated` is set to the 
tuple ("%s apples", 3).

> 
> If the above behavior is allowed then there are a number of additional language 
> level questions that should be addressed in the writing. For example, what does 
> the following produce?:
> 
> void foo()
> {
>      auto numApples = 3;
>      auto interpolated = i"$numApples apples";
>      numApples = 4;
>      writefln(interpolated);
> }

Tuples are expressions, not ASTs. Expressions are evaluated where they appear, 
which is true throughout D. Hence, the above `writefln` call is evaluated as:

     writefln("$s apples", 3);


> * Clarify and if and how new functions that take interpolated strings as 
> arguments can be written.
> 
> It is not clear from the DIP if users can write their own functions that take 
> interpolated strings as arguments. Similarly, it is not clear if/how Phobos can 
> add new functions taking interpolated strings as arguments.

Tuple expressions as function arguments are a longtime existing feature of D, 
and do not require re-explanation in the DIP.

It may indeed be the case that tuple expressions are inadequately explained in 
the language specification, but that is a problem that should be addressed with 
a bugzilla documentation issue, not this DIP.