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

[James Blachly]

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."

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" ?

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.

Kind regards