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

[Seb]

On Wednesday, 9 September 2020 at 14:19:43 UTC, Paul Backus wrote:
> On Tuesday, 8 September 2020 at 10:59:58 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community 
>> Review of DIP 1036, "Formatted String Tuple Literals".
>
> Scott Meyers has a talk, available on youtube [1], in which he 
> argues that the single most important software design guideline 
> is that "interfaces should be easy to use correctly, and hard 
> to use incorrectly." Let's assume, for the sake of argument, 
> that we all agree with him. (If you do not agree, feel free to 
> disregard this comment.)
>
> What this DIP proposes is an interface that is both hard to use 
> correctly, and hard to use incorrectly. While the efforts taken 
> to prevent misuse are admirable, the burden they impose on 
> programmers who merely wish to use string interpolation 
> as-intended is unacceptably high. Personally, I've supported 
> adding string interpolation to D in the past, but I would not 
> use it if it were implemented as this DIP proposes.
>
> I could point to specific details of the proposal that I think 
> lead to undue complexity, but I don't think I need to. The fact 
> that the DIP authors feel the need to devote as many words to 
> "justifications" of their proposal's complexity as they do to 
> actually explaining it in the first place is evidence enough. 
> They are well aware of what they have written, and of its flaws.
>
> I think the reason the DIP authors have ended up with such a 
> flawed proposal is that they have tried too hard to reach a 
> compromise between mutually-incompatible visions of what string 
> interpolation ought to be. Some people want compatibility with 
> `printf`, and others want compatibility with `writeln`, so we 
> end up with a proposal that's compatible with neither. Some 
> people want implicit conversion to `string`, others want 
> implicit conversion to `const(char)*`, so we end up with 
> explicit conversion required for both. And so on, for each 
> point of contention raised in every previous discussion of 
> string interpolation in D.
>
> This approach is fundamentally flawed. It can lead to Good 
> Work, but never to Great Work [2], and Great Work is the 
> standard that I expect a language addition like this will be 
> held to. As such, I do not think any version of this proposal 
> has much chance of being accepted by the language maintainers. 
> I recommend that this DIP be withdrawn.

I second this. I like this DIP more than 1027, but I fully agree 
with Paul that in its current form this DIP does too many wrong 
compromises. Just to re-state my points:

1) I strongly believe that printf shouldn't make up most of the 
design considerations and DIPs space. This is about a D feature, 
not C. Trying to bridge both worlds will please none.

2) No C string magic: "spec will automatically convert to a 
compile-time NUL-terminated C string if spec.hasAllSpecs is 
true." is just a big NO.

3) `${%d}bananas` is an awful syntax compromise as it will be 
very unintuitive to newcomers as it's not clear what the variable 
is.
For example, `${bananas:2f}` would read much better. In general, 
I like the way Python handles the format specifiers:

https://www.python.org/dev/peps/pep-0498/#format-specifiers

4) Format specifiers need to be 100% customizable. The NodeJS 
community got this right and it lead to a few awesome libraries. 
One example that has been mentioned before is 
https://github.com/chalk/chalk

5) APIs will need to be written specifically to cater for 
_d_interpolated_strings if no implicit conversion is allowed 
anyhow, so the interpolated_string struct should always 
containing its arguments. This would allow for adding methods 
like `idup`, `toString` etc. directly inside the struct. I don't 
see the DIP explaining the advantage of doing rewrite magic to 
`writefln(<interpolationSpec>, apples, bananas, apples + 
bananas);` and this will only confuse people.
More importantly, it severely restricts the freedom for function 
designers as they can not accept two interpolated strings nor 
argument afters the interpolated string.
Note that this also removes most-of the problems with "wrong-use 
of functions".

6) "if a StringLiteral follows an InterpolatedString, it is 
appended to the InterpolatedString in the parsing pass (not the 
lexer pass)". Automatic string concatenation was deprecated for 
good reasons. This DIP does not provide a good motivation for 
this nor explains how all the risks learned from this are 
mitigated.

7) A main use-case for interpolated strings is D mixins. It 
doesn't address combineing it with token strings  to create D 
code, e.g. `qi{class D { auto $varName = 20; }`

8) A lot of people want `string k = i"foo $bar";` to work and the 
DIP should at least a very good explanation why the compiler 
shouldn't rewrite such assignments to `string k = i"foo 
$bar".idup;` as it's very clear what the user wants here and the 
@nogc argument applies to normal strings as well.
In fact, the overload resolution could be changed, s.t. 
d_to_string struct overloads have a higher priority, but the 
`string` overloads are still being considered. The compiler would 
need to implement this logic anyhow to issue the mentioned: "Did 
you mean to use .idup?" messages.

9) The DIP does not mention operator overloading, e.g.

string s = "foo";
...
s ~= i"foo $bar";

IMHO this is unambiguous and would reduce the need to call 
`.idup`.