DIP 1027--String Interpolation--Final Review Discussion Thread

[Adam D. Ruppe]

Due to the silly rules, I have to correct Walter's errors in this 
thread instead.

On Tuesday, 4 February 2020 at 05:41:34 UTC, Walter Bright wrote:
> On 2/3/2020 7:48 AM, Steven Schveighoffer wrote:
>>
>> The rationale for this change is twofold:
>
> No rationale is given why this needs to be supported at all.

I suggest you read the post again.

Moreover, consider this use case. We have an existing function

Result query(T...)(string q, T args) {}

The format of the `string q` here is to use `?n` to refer to 
`args[n-1]`.

     query("X > ?1", x);

A user wants to try the new interpolated string on it. They try:

     query(i"X > $x");

It compiles! Then it launches nuclear missiles and self-destructs 
the computer. Turns out %s was the special code to `query` to 
indicate universal armageddon.

(ok it'd probably just throw a syntax error exception BUT THERE 
IS NO WAY TO TELL.)

I know what you're going to say. "the user needs to be aware of 
the string format". Well, there's no type system check so I 
*guarantee* you this is going to be a common problem. With a new 
type as an overload target, library authors can do something 
about it. Without it, well, I guess it means i'll get more irc 
posts and stack overflow points answering confused user's 
questions.

But let's assume they do know. Do they have to consistently write:

     query(i"X > ${?1}(x)");

Of course, by this point the new feature has lost its appeal. 
You've made the wrong thing easy and the right thing hard. D, at 
its best, does the opposite.


Or consider this:

    Window createWindow(string title, int width = 0, int height = 
0) {}

and the user writes

    createWindow(i"Window for $user_id on $pid")

it compiles... but throws an invalid argument exception (or 
creates a randomly sized window). Weird. (the addendum would 
still allow this by default, which I think is a mistake, but am 
compromising for your desired for compatibility with printf. But 
at least with the addendum, it becomes possible to for the 
library author to add `Window 
createWindow(T...)(InterpolatedFormat fmt, T args) { static 
assert(0, "sorry i didnt implement interpolation here try doing 
.format on your string instead");`

D has a type system for a reason. If anything, using it should be 
the default position and bypassing it requires special rationale!

So: why are you opposed to using it?

> Note that the user can always write:
>
>   writefln(i" ... $a ... ");
>   writefln(i" ... $b ... ");

That does not do the same thing as `writefln(i" ... $a ... ", i" 
... $b ... ")`.

But even if it did, what about nesting? What happens if someone 
tries

i"$(i"$foo") $bar"

what happens? Under the current dip rules:

     ("%s %s", "%s", foo, bar)

and you can't use that. It is impossible to tell where it was 
nested. (If you say "well, don't do that", I'd note the DIP makes 
no mention of it and does not prohibit it. So again, are we 
relying on user's voluntarily following best practices?)

Of course, even with this addendum, printf wouldn't detect it. 
But just because not ALL errors will be detected doesn't mean we 
shouldn't detect MANY errors.


> The user can write writefln(i"$percentage%% complete") as 
> required.

Again, relying on users to consistently do something (except when 
calling functions that do it differently!) with no help from 
compile errors / library design.

> Baking % into the specification with special escapes completely 
> weds it to printf/writef formatting, which is carefully avoided 
> (at your request!).

The current DIP bakes % into the specification. The addendum 
moves this to the library for both increased flexibility AND 
increased detection of user errors (without losing the DIP's 
(minimal) printf compatibility, at your request!)


> It's having the language semantics defined by a hidden template

This is just creating a type. Programs do this all the time.

foo("a") does something different than foo(1). foo("a"w) does 
something different than foo("a"). These are because they are all 
different types and foo is allowed to overload on the types of 
its parameters.

And guess what? With the DIP as-is, foo(i"$a") does something 
different than foo(i"$b"). They construct different types already!

All we're asking is that the format string itself also gets a new 
type for reliable detection in code. You need to justify why this 
is bad.

> (which happens nowhere else in D).
> [snip]
> The D compiler does such "lowering" to simpler forms in many 
> places already.

lol