The state of string interpolation

[Steven Schveighoffer]

On 12/6/18 3:00 PM, H. S. Teoh wrote:
> On Thu, Dec 06, 2018 at 02:27:05PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 12/6/18 2:12 PM, Paul Backus wrote:
>>> Marler's original proposal is simple, orthogonal, and elegant. It
>>> makes use of existing D features in natural ways, and is both easy
>>> to understand, and easy to use in simple cases without *needing* to
>>> understand it. I think adding additional machinery like
>>> FromInterpolation on top of it would be a mistake. If users want to
>>> opt in to that extra complexity, it can always be made available as
>>> a library.
> [...]
>> The more I think about it, the better it is to use the original
>> proposal, and just pass the parameters at compile time in order to
>> make it work. The non-string portions will be aliases to the
>> expressions or variables, making them easily distinguishable from the
>> string portions.
>>
>> So instead of my original db.exec(...), you'd do db.exec!(...),
>> exactly the same as before, just it's passed at compile time vs.
>> runtime. The runtime possibility is there too, but you wouldn't use it
>> in a database setting.
>>
>> This can be used to forward to whatever you want. If you want to
>> change the parameters to FromInterpolation("foo", foo), it will be
>> possible.
>>
>> This is very D-ish, too, where we supply the compile-time mechanisms,
>> and you come up with the cool way to deal with them.
> [...]
> 
> Yes, this.  I support this.
> 
> Now, I'm also thinking about how to minimize the "surface area" of
> language change in order to make this proposal more likely to be
> accepted by W&A.  Because as it stands, the exact syntax of interpolated
> strings is probably going to ignite a bikeshedding war over nitty-gritty
> details that will drown the core proposal in less important issues.
> 
> While it's clear that *some* language support will be needed, since
> otherwise we have no way of accessing the surrounding scope of the
> interpolated string, I wonder how much of the implementation can be
> pushed to library code (which would make this more attractive to W&A),
> and what are the bare essentials required, in terms of language change,
> to make a library implementation possible.

Why do we need support for accessing the surrounding scope? The 
passed-in variable aliases and expressions should be all that is needed.

[snip]

> Just throwing out some ideas to see if there's a way to do this without
> making a big change to the language that will likely be rejected.

I don't think we need to start with such a drastic addition. Let's start 
with lowering the interpolation string to the tuple, and see how far we 
can get from that.

-Steve