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

[SealabJaster]

On Wednesday, 27 January 2021 at 16:54:30 UTC, Steven 
Schveighoffer wrote:
> ...

+1

I'm quite biased, but this approach is more similar to how C# 
handles things, and not having to jump through hoops just to make 
a string is a lot more obvious and user-friendly.

I fear the ultimate fate of this DIP is rejection though, but in 
my not so honest opinion this is a better iteration of the 
previous attempt.

Honestly, pretty much all of my major points have already been 
argued by others during the last discussion of this DIP, so I 
don't really have anything new to add other than: What's the main 
priority between making it easy to use and obvious, or making it 
less easy to use for... reasons?

Why are we scared of adding usage of the GC for small quality of 
life things (implicit string conversion)? Even if the DIP 
specifies a way to avoid GC usage?

It's kind of like we're silently admitting that the GC is a 
hindrance, and so is to be avoided for any new features, which in 
turn (to my fragile c# eyes at least) is being compromised for 
making the obvious, common use cases (implicit string conversion) 
harder to use.

Which is why I believe this DIP's surface value is much better 
than the attempt before. I'm not able to comment on all the nitty 
gritty technical details though, which I understand may have 
issues.

Again though, I'm largely biased towards the most common use case 
being the simplest and most obvious use case. Which for people 
comparing this feature to languages like C# and JS, it'd be 
implicit string conversion that's out of your way.

And disclaimer on these thoughts: I personally have no interest 
in the tuple form of an interp string in spite of recognising its 
value and potential, so my bias is simply towards string 
conversion.

Finally, and I'm sorry if I missed this being described in the 
DIP, but consider this case (and similar):

```
void f(T)(T array)
if(isArray!T)
{
     //...
}

f(i"...");
```

What would happen here? My best guess is that it won't compile 
unless written as `f(i"...".idup)` which then introduces an odd 
discrepancy where there's certain usages that still require 
explicitly calling .idup, e.g. `i"...".idup.splitter`