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

[Steven Schveighoffer]

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.

-Steve