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

[Daniel N]

On Wednesday, 3 February 2021 at 22:15:45 UTC, Paul Backus wrote:
> On Wednesday, 3 February 2021 at 22:07:47 UTC, Daniel N wrote:
>> On Wednesday, 3 February 2021 at 20:12:24 UTC, Adam D. Ruppe 
>> wrote:
>>> On Wednesday, 3 February 2021 at 20:02:57 UTC, Daniel N wrote:
>>>> Wouldn't this lowering be both simpler and more more 
>>>> efficient?
>
> The idea is that, even when `interp!"whatever"` is passed as a 
> *runtime* argument to a template function, that function can 
> access the string "whatever" at compile time, because it's part 
> of the argument's *type* rather than its *value*.
>
> void fun(Args...)(Args args)
> {
>     static foreach (arg; args) {
>         static if (is(arg == interp!s, string s)) {
>             // Allowed to do this because `s` is known at 
> compile time
>             pragma(msg, s);
>         }
>     }
> }
>
> // prints "Hello " at compile-time
> fun(i"Hello ${name}");

Thank you! It is very impressive, brilliant and clever, yet I 
don't think it's the right way.

With a plain tuple it is possible to create a wrapper which 
generates DIP1036 style lowering (or simply work directly in the 
template with the value params).

template fun(T...) {
     void fun() {
         fun(interp!(T[0])(), interp!(T[1])());
     }
}

In order of greatness:
1) Opt-In  Bloat
2) Out-Out Bloat
3) Unavoidable Bloat <- Current DIP1036

Yes, as a library author you are forced to use value templates... 
but it still works, no real expressive power is lost.

Shouldn't we optimize for the common-case? (writeln and mixin)

Strings are ubiquitous, lowering to a plain tuple is the least 
possible bloat and also most powerful (support for ref etc), but 
with my proposed simplification you are now free to opt-in to 
more advanced meta programming _when you need it_, pay as you go!