Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1
james.blachly at gmail.com
Tue Sep 8 18:50:41 UTC 2020
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."
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.
More information about the Digitalmars-d