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

[Steven Schveighoffer]

On 9/12/20 11:23 PM, Walter Bright wrote:
> Under "Wrong-use in unrelated function" it says:
> 
> --------
>      Window createWindow(string title, int width = 0, int height = 0);
> 
> A user has some code that calls it like so:
> 
>      import std.conv;
>      auto window = createWindow("Process debugger " ~ to!string(pid));
> 
> A new version of the compiler is released and the user, eager to try D's 
> new string interpolation feature, rewrites that code as would be common 
> in many other languages:
> 
>      auto window = createWindow(i"Process debugger $pid");
> 
> This would compile without error, but would not do what the user intended.
> ----------
> 
> This is indeed correct, but I take issue with "as would be common in 
> many other languages". Because of D's close relationship with C, it 
> would be a fair statement to compare with C. But C doesn't have string 
> interpolation. It is impossible to constrain D based on what people 
> expect from "many other languages".

We meant what many other languages do for string interpolation 
specifically (there are quite a few users of Python that find a good 
home with D, I don't think we should ignore them because they didn't 
come from C). But let's put this on the back burner for a bit, the next 
version of the DIP I think will solve this problem in a cleaner way.

> 
> D should do what is best for D, not what is best for C#, Forth, or 
> Haskell. It is not unreasonable to expect people to at least glance at 
> the instructions before assuming D is just like Language X.

We agree with this, as I think actually there aren't really any other 
languages that have done string interpolation in this exact way. D has a 
chance here to really shine with its introspection capabilities and 
focus on lowering.

However, it's also good to look at what works in other languages, and to 
frame the expectations of cross-language developers. If we can make it 
work like they expect AND cater to D's tremendous introspection 
capabilities, we have a very big win.

> If they 
> don't (and we're all guilty of that) then they get to debug it, like 
> first noticing that the window title reads "Process debugger %s", which 
> is not disastrous.

I have been thinking a lot about "incorrect usage" and this DIP.

How many of us have done:

writeln("Name: %s, age: %d", name, age);

And are surprised when you get unexpected output. I do it all the time. 
And it's not terrible, I just fix it and move on.

Perhaps we put too much emphasis on the dangers of misuse. But I think a 
more reasonable pushback on the "surprise" factor here is that if call 
DOES happen to bind to an existing function not designed to take string 
interpolation tuples, the parameter ordering is much different than 
expected (Andrei pointed this out, and it's a very good point).

To be fair though, the biggest problem with the createWindow accidental 
match isn't necessarily the title, but the window width might be 20, or 
65000. Honestly, you might not even notice the title when your window 
appears to open with random sizes.

> #DIP1038 needs a much better rationale as to why it should be preferred 
> over #DIP1027.

Our next revision will be vastly different from DIP1027. So this is kind 
of a moot point.

> (On a related note, I propose that default arguments are an overused 
> feature, and should raise an eyebrow when used. There are many other 
> inadvertent problems one can run into with careless use of it.)

default parameters are a nice way to avoid having to write simple 
overloads which just call the other overloads. I wouldn't say this 
example is *completely* careless, but if I were to design it with this 
in mind, I probably would have provided a Size struct as the second 
parameter (and make it a default parameter).

The truth is, we don't always get to design the APIs we use, and if we 
can keep intact the expectations that the original designers had when 
designing them, the DIP is in a better place.

-Steve