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

[Paul Backus]

On Wednesday, 27 January 2021 at 10:33:53 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community 
> Review of DIP 1036, "String Interpolation Tuple Literals".

DIP 1036 takes two different approaches to string interpolation 
and attempts to merge them together into a single proposal. In 
broad terms, those approaches can be characterized as follows:

1. The convenient approach: the language and runtime take care of 
string conversion and memory allocation for you, and you don't 
have to worry about any of the details.

2. The flexible approach: the language splits the string apart 
into interpolated and non-interpolated pieces, and it's up to you 
to decide what to do with them.

DIP 1036's proposal for #2 is very good, and its proposal for #1, 
while missing some important details, appears to be fundamentally 
on the right track. Either one of these proposals would make a 
fine DIP on its own. The problem with DIP 1036 is in the way it 
attempts to combine the two.

Fundamentally, the goal that DIP 1036 is aiming for is to give 
the programmers who want convenience the convenient version, and 
to give programmers who want flexibility the flexible version. 
While this is an admirable goal, fully achieving it requires 
reading the programmer's mind, which is infeasible given D's 
current level of compiler technology. So what DIP 1036 does is 
attempt to *guess* what the programmer wants, using a rather 
crude heuristic: if the code compiles with the flexible version, 
the compiler is to assume that's what the programmer wants; 
otherwise, it assumes they want the convenient version.

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.

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 a desirable trait for a language 
feature that's intended to make programming *easier*.

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.