The state of string interpolation

[Mike Franklin]

On Friday, 7 December 2018 at 03:29:11 UTC, Steven Schveighoffer 
wrote:

> 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.

Understood.  In Jonathan's PR Andrei challenged the merit of a 
language string interpolation feature because a library solution 
already existed, and it wasn't being heavily utilized.  I think 
that overlooks the fact that perhaps the reason the library 
solution is not heavily utilized is because its syntax is not 
very elegant.  But I think he also simply wanted the potential of 
a library solution to be thoroughly investigated.  That is what 
is supposed to happen in the DIP process.

I still think there could be some general, broadly useful 
features to add or limitations to remove so we could build 
something like this without having to justify it to anyone.

>> 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.

[..]

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

Yep, that's one of the features I had in mind.  We already have 
it at runtime; would be nice to have feature parity at 
compile-time.  Maybe it wouldn't do anything to help the problem 
at hand though.  I'll have to spend some time on it.

Mike