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

[Jon Degenhardt]

On Thursday, 30 January 2020 at 09:47:43 UTC, Mike Parker wrote:
> This is the feedback thread for DIP 1027, "String 
> Interpolation".

* 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?

* 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.

* 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.

* 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.

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);
}

* 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.