Feedback Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1
snarwin at gmail.com
Wed Sep 9 14:19:43 UTC 2020
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 , 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
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 , 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.
More information about the Digitalmars-d