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

[Paul Backus]

On Tuesday, 8 September 2020 at 10:59:31 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community 
> Review of DIP 1036, "Formatted String Tuple Literals":

As per the rules, I'm responding here to Steven's post from the 
Feedback thread.

Steven Schveighoffer wrote:
> 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.

Thanks for replying. The specific, actionable item in my post is: 
withdraw the DIP.

This kind of feedback ("related to the merits of the proposal 
rather than to the contents of the DIP") is explicitly permitted 
in Community Review by the Feedback thread rules, which is why I 
posted it there instead of in the Discussion thread.

The reason I gave that feedback, instead of more detailed 
feedback about the DIP's contents, is that I sincerely believe 
DIP 1036 cannot be salvaged. I have a lot of respect for you and 
Adam, and would hate to see you waste your time and effort on a 
proposal doomed to failure. I think you (or anyone else who 
wishes to take up the string-interpolation torch) would be much 
better off discarding DIP 1036 and starting a new proposal from 
scratch.

Regarding the specific points you replied to:

> The interface is actually simple to use. Without specific 
> concerns, it's hard to address these comments further.

If the interface is simple to use, why does the DIP anticipate 
that new users will have so much trouble using it that they'll 
need "helpful hints" from the compiler, and possibly even a link 
to a web page (!), to get it right? I quote:

> An i"" string is not likely to be compatible with existing D 
> string functions and variables. The compiler SHOULD provide 
> helpful hints in error messages to help new users understand 
> how to properly use the new feature. This message MAY link to a 
> web page to educate the user on resolving the error.

To me, this does not pass the laugh test. [1] If you anticipate 
this being hard enough to get right that new users cannot do it 
without extensive hand-holding, maybe the problem is not with the 
users, but with the proposal itself.

> 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.

Again, I quote:

> ### Justifications
>
> The **complexity** of the format spec may seem superfluous, 
> however it serves four key roles:

Emphasis added. If you want to nitpick the wording here, take it 
up with your co-author.

> 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 members of this community sometimes give the language 
maintainers (currently Walter and Atila, previously Walter and 
Andrei) too little credit. They're not perfect, but generally 
speaking they are reasonable people with good judgment. Have 
there been any actual examples of a DIP being rejected on 
principle for being too similar to another previously-rejected 
DIP?

> 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.

"X is true in the circumstance that Y" is not the same thing as 
"X is true." :)

Also, the fact that i"${%s}(foo)" and i"$(foo)" are equivalent 
when you pass them to `writefln` but not when you pass them to 
`printf` is another thing that doesn't pass the laugh test. 
You're not making it easy for me to tell my friends about D.

> 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 understand perfectly. My criticism of DIP 1036 is not that you 
have failed at what you set out to do, but that you have set out 
to do the wrong thing to begin with.

By the way, there's another part of that Scott Meyers talk that 
addresses the problem of accidentally passing arguments to the 
wrong parameters. The solution he shows there would also work for 
the example in the DIP, without requiring any of the elaborate 
machinery the DIP proposes.

> 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.

Adding dedicated overloads of writefln, idup, etc. to deal with 
interpolated strings might sound like a good solution, but it 
doesn't scale. The *best-case* scenario is that DIP 1036 creates 
a bunch of meaningless busywork for library maintainers; the more 
realistic scenario is that most libraries never get updated at 
all, and users have to either check every individual function 
they use for interpolated-string compatibility, or defensively 
spam .idup everywhere (at which point, you might as well just 
make interpolated strings use the GC to start with).

In other words, DIP 1036 is exactly the kind of thing Andrei is 
describing when he talks about Good Work [3]:

> Good Work begets more Good Work. Typically Good Work produces 
> context, opportunity, and precedent for more of the same. The 
> same reviewer who rubber stamped a piece of Good Work will have 
> an idea how to produce more Good Work derived from it. The kind 
> of environment where Good Work is revered encourages its 
> creation, in a cycle that creates the illusion of progress. 
> Because Good Work is complex, it produces "bug ripples" whereby 
> increasingly complex Good Work fixes one bug but is liable to 
> introduce others.

DIP 1027 had its issues, but at least it was simple to explain, 
simple to use, and didn't require the library and runtime to bend 
over backwards to support it. DIP 1036, by contrast, is hard to 
explain, fiddly to use, and requires extensive coordination 
between the compiler, runtime, and library to implement. In 
short, it's a step in the wrong direction.

[1] "Can I explain this to my friend, who doesn't know D, with a 
straight face?"
[2] https://www.youtube.com/watch?v=5tg1ONG18H8&t=46m14s
[3] 
https://forum.dlang.org/thread/q6plhj$1l9$1@digitalmars.com?page=15