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

Jonathan Marler johnnymarler at gmail.com
Thu Dec 12 05:07:44 UTC 2019


On Wednesday, 11 December 2019 at 09:52:21 UTC, 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.

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.

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.

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

// by lowering to a tuple, you would get this
writeln(i" ... %a ... ", i" ... %b ... ");
// becomes
writeln(" ... ", a, " ... ", " ... ", b, " .. ");

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.



More information about the Digitalmars-d mailing list