Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1
schveiguy at gmail.com
Tue Sep 8 20:41:00 UTC 2020
On 9/8/20 2:50 PM, James Blachly wrote:
> On 9/8/20 6:59 AM, Mike Parker wrote:
>> This is the discussion thread for the first round of Community Review
>> of DIP 1036, "Formatted String Tuple Literals":
> I am really, really happy to see string interpolation coming to D, but I
> have a concern with the implementation as described in the DIP. Viz:
>> An i"" string is not likely to be compatible with existing D string
>> functions and variables. The compiler SHOULD provide helpful hints in
>> error messages to help new users understand how to properly use the
>> new feature. This message MAY link to a web page to educate the user
>> on resolving the error.
> a bit (even nicer now that Python3 has f-strings), and in my estimate
> the proportion of uses with print() (or other language equivalent)
> versus other uses is at most 50/50. i.e., string interpolation is OFTEN
> used in many contexts beyond simply printing a message to the user.
> I read the sections "Usage in existing string-accepting functions" and
> understand `isInterpolationSpec`, and subsections "Wrong-use in
> unrelated function" and "On implicit conversions."
One thing to note here is that i"..." results not in a single thing, but
a list of things. So it's not really possible to provide the mechanism
we are providing AND have the whole thing implicitly convert to a single
string. Much of the arguments about "wrong-use" are aimed at the
previous DIP and why we feel this mechanism for the format string is better.
Another previous suggestion (by Adam actually) is to wrap the entire
thing into a single type, and encapsulate the list of parameters inside
that. If we did it that way, then you could potentially automatically
convert the whole thing to a string implicitly using existing facilities.
But, you do lose some important capabilities. For instance, you would
now be passing a copy of each item, instead of the item itself. This has
issues that are not easily solved (for example forwarding refness, or
binding to an alias).
To me it's a choice between not having to specify .idup when you want a
string (which necessarily has to allocate, even if it's implicitly done)
vs. compile time goodies that come from expanding a thing into a
compile-time list. Not only that, but there are already functions which
use this mechanism of format + args, and attaching this feature to those
functions is going to be much smoother if the parameters are parameters
and not stuffed into a struct.
This is why we went with the .idup route -- it's simple, easy to write,
and already has a well-defined meaning. On top of that, it is a known
signal that GC allocations are happening.
> The authors argue:
>> To avoid unintentional bugs in libraries that don't anticipate
>> interpolated strings, this DIP does not recommend implicit conversion
>> of the interpolation spec structure to string, ... The logic behind
>> this decision is that, when making the additional effort to explicitly
>> write format specifiers for all interpolated values, the user will
>> have demonstrated significant understanding of how the feature works
>> both in general and for a specific use case. In that scenario, we can
>> allow implicit conversion so the interpolated string can be used by
>> existing functions.
> They then provide an example using printf.
> Ignoring for a moment C functions, what is the anticipated issue "with
> existing functions [and] the safety of accidentally calling existing
> functions inappropriately" ?
This is the part that's aimed at DIP1027, and why we felt you should be
able to overload based on the format string type, and that it should not
automatically work for things like the createWindow example.
others), and expect the function to work as a string generator. We hope
that the implementation in the compiler is smart enough to suggest the
correct usage when the argument type mismatch is detected.
> Thanks again to the authors. I really truly think this is important
> work and thank them, but if the barrier to entry for a SEEMINGLY
> "simple" feature is too high, this makes D much less approachable for
> new users, about which I believe we should be very concerned.
It's a valid point. The full explanation of why we wrote the DIP this
way is not essential to explaining the feature. In documentation, it
might be good for ddoc to have a special notation for functions that
accept formatted string tuple literals (i.e. collapse the interpolation
string format and varargs that follow into one parameter). Then usage is
simple, but one still has to understand the mechanisms to provide
functions that accept such parameters. Though a simple tutorial and
examples will go a long way.
BUT, one still has to be wary of how the first argument, if it is an
interpolation literal, may consume multiple parameters for the function.
For functions that are defined without varargs, it's going to be highly
confusing. I would be very surprised if any interpolation string tuple
accepting function is not a template varargs one.
More information about the Digitalmars-d