The state of string interpolation

[Steven Schveighoffer]

On 12/6/18 7:43 PM, Mike Franklin wrote:
> On Thursday, 6 December 2018 at 22:04:13 UTC, Steven Schveighoffer wrote:
> 
>> It's really not what's enabled (clearly, things can still be used 
>> without string interpolation, and we can use mixins to simulate close 
>> to what we would want).
>>
>> It's how one writes and reads code. The efficiency and elegance is not 
>> to be ignored.
> 
> [..]
> 
> Of course, you are right, and that's what I was trying to say. "What 
> language feature do we need, or limitation removed, that gets us what we 
> want:  the ability to implement interpolated strings and potentially 
> other features in the library without too much compromise on the 
> efficiency, elegance, and expressiveness you would get if you 
> implemented it in the language, and without turning D into a DSL".  That 
> probably doesn't do it justice either, but I hope you get the idea and 
> we're on more-or-less the same page.

I get the idea, but the answer is, nothing. We can implement it today 
(take a look at scriptlike).

As long as there is an insistence that 'if it's doable in the library, 
the elegance is not worth the effort,' any proposal will fail. We need 
to first convince those in charge think the feature should be added 
because of the *human* impact. That was the point of my longer answer.

> Jacob mentioned AST macros (I knew that was coming, and even had a note 
> in my first draft say "Sorry, Jacob, except for AST macros", but I 
> deleted it :D ).  But Jacob is on to something. We already pass around 
> symbols with `alias`.  Can that be extended somehow to pass around 
> expressions too (i.e. expressions as rvalues)?  That would probably help 
> address the issue of printing assert expressions as well 
> (https://github.com/dlang/dmd/pull/8517)

I think we can't exactly pass around expressions in the general case, 
because it's too fraught with ambiguity.

For example, if foo accepts an alias, then what is foo!(a + b)? Today, 
if a and b are compile-time known, then it's the sum of a and b. If a or 
b cannot be determined at compile time it's an error.

If foo!(a + b) all of a sudden compiled for runtime variables, but did 
something wildly different, we would probably have issues.

I think we would need a new type of alias. My hope was that we could let 
this remain without syntax, and just say it's only accessible if you use 
string interpolation. This makes the change simpler to implement, and 
narrowly focused.

However, if I had to give it a name (and syntax), I'd say it's a lazy alias.

> 
> As for myself, I don't see much value in forcing users to add `mixin` at 
> the site of a mixin template instantiation, but there's a lot I don't 
> see, so I may just be missing something.
> ```
> import std.stdio;
> 
> mixin template Foo(T)
> {
>      T x = 5;
> }
> 
> extern(C) void main()
> {
>      // Why do we need `mixin` here?
>      // Why can't we just write `Foo!int;`?
>      // It's already yelling at us with a ! operator.
>      mixin Foo!int;
>      writeln(x);
> }
> ```

I think the reason is that you are giving the template free access to 
ALL your scope. My expectation of the string interpolation mechanism is 
that it only gives access to the variables or expressions passed to it. 
I think it's probably a good thing to require mixin for a flag to look 
for, even if it's ugly.

vibe.d does string interpolation in it's diet templates, but the rub is 
that you have to pass in an alias to the variables you want to be 
visible in the interpolation. So it requires a very un-DRY solution, and 
also doesn't work with arbitrary expressions.

> Simen Kjærås mentioned a few things when we were discussing ways to 
> implement properties in the library at 
> https://forum.dlang.org/post/jqcqsriizuewdqotbnop@forum.dlang.org  There 
> might be some feature to be added, or limitation removed, that will 
> permit help both the string interpolation case and the properties case.
> 
> I know I'm just thinking out loud and not contributing much, but I can't 
> help but feel that there's something common in all these ideas that just 
> hasn't been identified yet.  And no, Jacob, not AST macros (Actually, 
> that would probably do it, but I think we've already been there) :D

As I said, there's already possible libraries that allow what we want. 
It's the usage syntax that is the pain-point I would say.

-Steve