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

[Andrei Alexandrescu]

On 9/9/20 5:41 PM, Paul Backus wrote:
> 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

I quoted this in its entirety because I agree with it in its entirety. 
It says what I wanted to say, in a much better form.

"Principle of Least Astonishment" 
(https://wiki.c2.com/?PrincipleOfLeastAstonishment) also comes to mind 
(incidentally I've first heard of it from Scott Meyers, too, but it 
probably predates him). I found some design choices surprising: We care 
about printf and its style of formatting. But we don't care for POSIX 
positional parameters. Yet we should design functions especially for 
interpolated strings. We move arguments to the end of the format string. 
The format string is actually not a string - per the infamous error 
message with a web link to educate the user. All of these are surprising.

These high-level decisions require a series of technical solutions that 
come in the form of a runaway train of engineering.