DIP 1027---String Interpolation---Community Review Round 1

[Steven Schveighoffer]

On 12/12/19 12:07 AM, Jonathan Marler wrote:
> 
> Lowering interpolated strings to a format string and a tuple of values 
> rather than just a tuple is less versatile than other solutions that 
> have previously been proposed.  This DIP pigeon-holes interpolated 
> strings for one use case.  Interpolated strings can be used for more 
> than just creating strings.  They are just a pretty syntax to interleave 
> string literals and expressions. This solution is assuming the user will 
> only use this for string formatting, but that's not necessarily the case.

Indeed, one can potentially have more use cases than format string plus 
tuple. That is one thing I don't like about it. But any technique we use 
to forward tuples and string formatting to a function is going to 
require adjustment in some cases, and work as-is in others.

We did have problems with the straight tuple lowering (i.e. how do you 
tell which part was string literal and which parts were parameters). the 
new proposal handles that quite well in fact.

Not to say that this isn't solvable, but I do like that aspect of the 
new DIP -- the string literal parts are clearly defined. It definitely 
needs changing from its current mechanism (the requirement of % for 
placeholder is too limiting IMO).

One thing that might make things more useful -- if the compiler could 
define a new type istring, which is a derivative of string literal, and 
one could accept that as a parameter type for purposes of overloads if 
needed.

> My original proposal lowered it directly to a tuple of string literals 
> and expressions (https://github.com/dlang/dmd/pull/7988) and Adam 
> Ruppe's proposal 
> (http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html) lowered 
> it to a custom type where the same tuple could be accessed via a field.  
> These solutions provide more versatility and are just as easy to print 
> and format into strings with a single function call. Adam Ruppe's 
> proposal was more complex than my own but improved versatility (i.e. 
> added a method to convert it to a string without importing a module, 
> allowed functions to overload on interpoated strings, provided access to 
> the original raw un-interpolated string, etc).  The problem with this 
> DIP is that it's both more complex than my original proposal and less 
> versatile.

I think all of them are somewhat equally versatile. With a mechanism to 
specify how to generate the format string, such as H. S. Toeh suggested, 
I think Walter's proposal is just as useful as yours or Adam's. All of 
them provide somewhat similar transformations, just the ordering of the 
string parts and the non-string parts are different. Unfortunately, I 
don't know if there's a way to forward the "tuple-ness" of the result by 
wrapping it if you needed to convert something.

Even though Adam's proposal allows one to translate between what the 
compiler generates and what is needed, it copies the tuple into a type, 
which may not be what you want (e.g. Walter's example for apples, apples 
is an lvalue, but in Adam's it would always be an rvalue).

There are limitations in yours as well, I like the ability to specify 
the formatting of the individual items, which would be difficult if not 
clunky in your proposal.

> 
> The other problem with this DIP is how it handles consecutive 
> interpolated strings.  Consider a case where you'd like to write a 
> message with consecutive interpolated strings (see real life example 
> here 
> https://github.com/dlang/dmd/pull/7988/files#diff-685230fdddcb87fcbb4a344b264a2fb6L736): 
> 
> 
> // using this DIP
> writefln(i" ... %a ... ", i" ... %b ... ");
> // becomes
> writefln(" ... %s ... ", a, " ... %s ... ", b);
> // that doesn't work, so you'd have to do this
> writeln(i" ... $(a) ... ".format, i" ... $(b) ... ".format);

that does pose a slight problem, but one could potentially handle that 
with concatenation (i.e. concatenation of two interpolated strings 
results in the same thing as if you concatenated the two string literals 
and slapped i on the front).

> 
> I also don't see any mention of my proposal in the DIP in "Prior Work" 
> or how this DIP compares to my proposal or Adam's.
> 

This should be rectified.

-Steve