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

[Adam D. Ruppe]

On Friday, 29 January 2021 at 18:49:18 UTC, Paul Backus wrote:
> To be clear: you can still have both, just not with the same 
> syntax.

Steven and I argued for a little over this topic. I was of the 
opinion that only the tuple return is necessary - it is trivial 
to convert to string on demand by calling a function.

The argument that swayed me is that user habit will start to be 
wrong. Look at what people do with .array on ranges. It is used 
all over the place, including in places where it is pointless. 
People recommend it out of habit, not out of consideration.

.array is basically harmless though. Using it unnecessarily just 
wastes time and memory while still doing the right thing.

On the other hand, with these interpolated results, misusing it 
results in potentially serious problems, like sql injection, that 
library code may not be able to warn about*. So we really don't 
want it to be an unthinking habit.

The more cases where plain i"" does the right thing, the more 
likely the user is to actually use it instead of developing 
harmful habits.

And while you're arguing in this thread, the other threads had a 
lot of people saying the basic case just working is important to 
them. Since retaining Python users is a solid growth area for D, 
I do think we should listen to them and reduce their initial 
friction.

I still do agree this implicit conversion part is certainly more 
complex than the rest of the proposal combined and still have 
some reservations myself, but it would be nice to have. Either 
way, whether it is there or not, some user education is required 
for them to understand that i"" is not *really* some string, but 
rather a string builder (just perhaps with some implicit 
conversions). I don't believe this is a dealbreaker. It is just 
like how we have to educate users about value range propagation 
and range semantics and such. A lot of knowledge carries over, 
but it isn't exactly the same to other languages because D wants 
to leverage its unique strengths.

* one option would be to not have a string overload *at all* in 
the library, or at least give it an ugly name or something. The 
big problem there is just doing it in a way that's compatible 
with today's D, but it certainly is worth considering.