Feedback Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1
schveiguy at gmail.com
Wed Sep 9 16:14:37 UTC 2020
On 9/9/20 10:19 AM, 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".
First, thanks for your opinion. We value all the opinions of people in
the community, especially long-standing members with a lot of experience
with D such as yourself.
However, this entire post has no actionable or specific items, and
really should have been added to the discussion thread instead. I'm
responding to it here because in the past I have had cases where I
posted feedback and got no response or changes, and it irked me.
> 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.
The interface is actually simple to use. Without specific concerns, it's
hard to address these comments further.
> 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.
This measure of "complexity" is arbitrary, and has no bearing on the
validity of the DIP. in fact, many already-accepted DIPS have relatively
similar ratios of description and rationale.
One thing to note is that this DIP has a prior very similar DIP, but
just used a string for the formatting specification. The Justification
section is ENTIRELY devoted to explaining why this DIP does not use
that. In fact, we can remove the entire section, and it doesn't change
anything about the DIPs features or benefits. But without a distinction
between DIP1027 and this DIP, arguably it would be rejected on principle
(why approve something that was just rejected).
> 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 assessment is incorrect. There is an implicit conversion of the
format specification to immutable char * in the circumstance that you
have specified all format information. This makes it compatible with printf.
Implicitly converting the format spec to string would result in
undoubtedly incorrect function calls, and we address the concerns quite
thoroughly. Even if it is a desired thing, it's not something we should
provide. This is not the same as trying and failing. We intend misuse of
string conversion to not compile.
I would characterize the DIP as not only trying to address these issues,
but succeeding. printf is supported for valid cases. writefln will be
supported as expected. Conversion to string or immutable char * is
possible with a library call which should be provided. There are no
flaws I can see.
More information about the Digitalmars-d