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