Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Steven Schveighoffer]

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":
>>
>> https://github.com/dlang/DIPs/blob/15537f9b36afa48f1c1cd57468e8c77f8f2499dd/DIPs/DIP1036.md 
> 
> 
> 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.
> 
> When I am writing Javascript or Python, I use string interpolation quite 
> 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. 
Specifically for people who are used to Javascript or Python (or 
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.

-Steve