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

[Dukc]

On Thursday, 28 January 2021 at 14:58:36 UTC, Steven 
Schveighoffer at the feedback theard wrote:
> On 1/28/21 3:35 AM, Dukc wrote:
>> The DIP states that foo(i"a:${a}, ${b}.") is rewritten as 
>> `foo(Interp!"a:", a, Interp!", ", b, Interp!".")`. It think 
>> it's better to rewrite it as `foo(Interp!"a:", 
>> Interp!typeof(a)(a), Interp!", ", Interp!typeof(b)(b), 
>> Interp!".")`. That way, `foo` has easier time introspecting 
>> which came from the interpolated string.
>
> First, I don't think it's critical for overloading, and will 
> simply add to the template bloat. What are you going to do 
> differently with `a` than you would with 
> `Interp!(typeof(a))(a)`?

I was mainly thinking that I'd have easier time differentiating 
between an `int` in interpolated string and `int` passed 
before/after the interpolated string. And I have a type that will 
implicitly convert to string if I want to do that - no need to 
call `to!string(a)` or `a.Interp!(typeof(a))` first.

> The parameters are guaranteed to start and end with an 
> InterpolationLiteral, so one can assume that non-literal 
> arguments are interspersed inside the literal.

It can be done, but it sounds more complex for the introspecting 
function. I'm not strict about this though, what the DIP now 
proposes be worth it to be able to pass `ref` parameters in 
interpolated strings.

>
>> The type of interpolated string literal is very special cased. 
>> [snip]
>
> I was fully aware that this would be the most controversial 
> part. I feel like it will not be full of corner cases, but I'm 
> not sure. Can you specify any?
>
> Consider a normal string literal can be used as a string, 
> immutable(char)*, wstring, or dstring. I find it very similar 
> to this feature, and I don't feel like there are a lot of 
> corner cases there.

A string literal is a string that is implicitly assignable to the 
other alternatives via value range propagation mechanics, or 
that's how I understand it at least.

The compromise that the interpolated string would be an expanded 
tuple, that would be implicitly assignable to string via value 
range propagation mechanics, sounds acceptable. But it needs to 
be clear IMO what the primary type of an interpolated string is. 
If it is not an expanded tuple, what it is then? I mean that this 
must be guaranteed to pass IMO:

```
auto interpolation = i"&{apples} apples and ${oranges} oranges";

static pure int foo(typeof(interpolation));
static void foo(string){assert(0,"this must not be called");}

assert(foo(interpolation) == foo(i"&{apples} apples and 
${oranges} oranges"));
```

>
>> Let me suggest an alternative: [snip]
>> 
>
> We have considered that. The problem is that people will use 
> the string interpolation form without realizing the dangers or 
> resulting bloat.
>
> For instance, writeln(i"Hello, ${name}"), if made to 
> proactively generate a string just to send it to writeln is 
> extremely wasteful when writeln(I"Hello, ${name}") is not.

I don't think it's that bad, we tend to do stuff like 
`writeln("hello, " ~ name)` anyway. Relatively small 
inefficiencies like this don't matter in non-critical places, and 
critical places need to be benchmarked and optimized anyway.

Or did you mean template bloat? From that perspective I don't see 
difference. The first case will cause a new `idup` instance that 
interprets `name`, the second will cause a `writeln` instance 
that has similar interpretation mechanics.

>
> Consider also that code which uses a dual-literal system might 
> have to use the string interpolation form because the library 
> only allows that. Then at some point in the future, the library 
> adds support for the expanded form. Now the user would have to 
> go back and switch all usage to that new form, whereas an 
> auto-rewrite would just work without changes.

True, but the user can just continue to use the old form. If it 
was good enough until then, why hurry switching? Besides, the 
migration path is very easy.