On Friday, 20 October 2023 at 08:03:55 UTC, Walter Bright wrote:
>On 10/19/2023 6:52 PM, Steven Schveighoffer wrote:
>The point is that it's too easy to match to strings, compile, and do a completely unexpected thing. And yes, that's the major reason why 1027 is so bad.
I don't recall this issue even being discussed in the old review of it. It isn't listed in the review objections for DIP1027.
No it's not listed (which surprises me), and the thread is huge, I don't feel like going through it all.
I do remember objecting to it though, on the grounds that you can't overload based on a string.
For example, I have in mysql-native a function:
ulong exec(T...) (Connection conn, const(char[]) sql, T args)
Which accepts the statement in the mysql format of using ?
for placeholders. In order to accept an interpolation tuple, I'd have to name a new function:
ulong execi(T...) (Connection conn, const(char[]) sql, T args)
Which then forwards to the real exec
. And there would be no way for the compiler to prevent the user from using either with the incorrect parameters. AND the execi
function needs to parse the format string at runtime replacing "%s" with "?".
Whereas, YAIDIP and DIP1036 provide a way for the exec
function to be overloaded with interpolation literals, and always do the right thing at pretty much no runtime cost (the building of the string can be at compile-time).
But I undestand you don't like this, and there is a rather nice solution. Recall Andrea Fontana's example:
void deleteFiles(string[]... files) { ... }
As a special case, an i-string will not be a match for string[]...
. This makes sense, as a function requiring a format string would not be expecting no string. A match would have to be of the form:
void deleteFiles(string fmt, ...) { ... }
Just another whacked mole? What about the Exception problem?
throw new Exception(i"Invalid integer value in $file: $val");
-Steve