Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2

[Paul Backus]

Continuing from the feedback thread...

On Friday, 29 January 2021 at 16:55:05 UTC, Steven Schveighoffer 
wrote:
> On 1/28/21 6:06 PM, Paul Backus wrote:
>> As with any heuristic or approximation, there are edge cases 
>> where this breaks down. One of them is called out in the DIP 
>> itself--type inference via `auto`--but it is not hard to 
>> imagine others. For example, a programmer who writes
>> 
>>      tuple(i"Good morning ${name}", i"Good evening ${name}")
>> 
>> ...is probably not going to get what they intended, even 
>> though their code compiles.
>
> This is quite the unique edge case though. Any proposal that 
> provides the flexible version is going to have trouble with 
> tuple as it is now.

You are missing the forest for the trees here. My criticism of 
DIP 1036 is not
that it has trouble with `tuple`. My criticism is that DIP 1036 
attempts to
guess what the programmer wants, because guessing what the 
programmer wants is
bad language design.

> There are solutions that can be had. For instance, tuple could 
> be instrumented never to accept parameters that contain 
> interpolation literals. Therefore, the idup rewrite happens, 
> and they get what they expect. This is not hard to solve.

What was it Andrei said about this kind of thing? Ah, right:

     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. [1]

When you find yourself saying things like "it's fine, we can just 
add special
cases to printf...and tuple...and mixin...", that's a sure sign 
that something
has gone wrong in your language-feature design.

>> Every D programmer who wants to make effective use of DIP 
>> 1036's interpolation literals will have to go through the 
>> process of learning when .idup is required, when it's 
>> optional, when it's allowed-but-unnecessary, and when it's 
>> forbidden--which means that, in practice, they will have to 
>> learn how it actually works, under the hood.
>
> This is not my interpretation at all. I can't think of a 
> reasonable case aside from your tuple example where idup is 
> required (if that's what you want). Can you?

Sure, here's another one:

     anySatisfy!(isSomeString, i"I have ${count} apples")

Hopefully this is enough to satisfy you that it's your 
imagination that's
failing you here, not my reasoning.

>> This is not a desirable trait for a language feature that's 
>> intended to make programming *easier*.
>
> Your logic is not very sound. It's ironic to say the language 
> doing what you expect for 99% of cases is a higher burden than 
> requiring you to write it yourself for 100% of cases.

A language that does unexpected things 1% of the time is much 
worse than a
language that does exactly what I tell it to 100% of the time.

>> Ultimately, I think attempting to guess the programmer's 
>> intent is the wrong way to go here. Either force them to spell 
>> it out explicitly (with a call to .idup, .text, etc.), or take 
>> away the choice and give up on one of the two approaches.
>
> I want to say something about this idea of doing only one or 
> the other.

To be clear: you can still have both, just not with the same 
syntax.

If you want both, my recommendation would be to use the i"..." 
syntax for the
convenient string version, and qq"..." ("quasiquote") for the 
flexible
tuple version. At that point, it would probably make sense to 
split them into
two separate DIPs, too.

[1] https://forum.dlang.org/post/q7u6g1$94p$1@digitalmars.com