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

[Steven Schveighoffer]

On 12/11/19 4:52 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for 
> DIP 1027, "String Interpolation":
> 
> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md 
> 
> 
> All review-related feedback on and discussion of the DIP should occur in 
> this thread. The review period will end at 11:59 PM ET on December 25, 
> or when I make a post declaring it complete.
> 
> At the end of Round 1, if further review is deemed necessary, the DIP 
> will be scheduled for another round of Community Review. Otherwise, it 
> will be queued for the Final Review and Formal Assessment.
> 
> Anyone intending to post feedback in this thread is expected to be 
> familiar with the reviewer guidelines:
> 
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> 
> *Please stay on topic!*
> 
> Thanks in advance to all who participate.

First, I like the concept. It fixes the issue of "which parameters are 
string literals and which are variables?" issue of the straight 
lower-to-tuple design.

But there are a couple problems.

This is very much focused on writef and printf. What about other 
functions that accept similar string + arg tuple, but don't use %s 
specifiers? Perfect example is SQL:

query("select * from sometable where date < ?", someDate);

With the interpolation string:

query(i"select * from sometable where date < %someDate");

This translates to:

query("select * from sometable where date < %s", someDate);

which is not correct SQL syntax.

This means I have to create a separate function that accepts 
interpolated strings (can't be the same name because it would be the 
same parameters for overloading!) and inside that function, I need to 
TRANSLATE the formatted string into something sql can understand. Not 
only that, but I have to do it at runtime, since query accepts a string 
as a runtime parameter.

Not only that, but this doesn't provide a mechanism to hook compile-time 
format strings at all, even though the format string is known at 
compile-time.

The other problem is that you are using % for the interpolated fields. 
This is quite puzzling, considering that the main target (printf and 
writef) uses % as the format specifier. Why not just change the 
specifier to $ or {} or \() or \{} or literally any of the other 
interpolation systems out there. Then you don't need the %%%% mentioned 
elsewhere to make one percentage sign.

If we can think of a way to hook the string generation and have the 
parameters come afterwards, that would be ideal.

For example, if you lowered (and I'm going to use a better format 
specifier here):

i"I ate \({d}apples) and \(bananas) totaling \(apples + bananas) fruit."

to

InterpStr!("I ate ", FormatSpec!("d"), " and ", FormatSpec!(""), " 
totaling ", FormatSpec!(""), " fruit."), apples, bananas, apples + bananas

Where InterpStr and FormatSpec were defined by the library to be 
whatever Druntime specified, then you could handle any cases, and 
provide the most . For example, writef could accept the type as the 
first parameter, and translate easily into a standard writef call, or 
avoid having to parse the format specifiers all together!

This wouldn't work with printf. But I'm not so sure that's a huge 
problem. One could easily wrap printf in something D-ish.

Again, like the concept, but it's too narrowly focused on printf and writef.

-Steve