DIP 1027---String Interpolation---Community Review Round 1
schveiguy at gmail.com
Thu Dec 12 19:12:11 UTC 2019
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
> 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
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
> // 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.
More information about the Digitalmars-d