The state of string interpolation...one year later

[Jonathan Marler]

On Monday, 18 March 2019 at 12:12:12 UTC, Kagamin wrote:
> On Sunday, 17 March 2019 at 18:32:55 UTC, Jonathan Marler wrote:
>>>> foreach (i; 0 .. 10)
>>>> {
>>>>     mixin(interp(`$( i ~ ")" ) entry $(array[i])`));
>>>> }
>>>
>>> That doesn't look nice, does it?
>>
>> Not sure if you realize this but you're criticizing how the 
>> library solution looks, which was one of my main points :)
>
> I mean $( i ~ ")
>

Yeah, like I said you wouldn't write that in real code. It's an 
example to demonstrate something that would be hard for a library 
to parse.

>> And it's a contrived example to demonstrate an example that 
>> would be hard for a library to parse.
>
> It's hard to parse even for a library? That sounds bad.

Yeah it is bad. Hence why I listed it as a CON of the library 
solution. But it's very easy if it's implemented in the compiler 
since is has access to the parser.

> Is it required to be hard to parse?

The problem is knowing when right-paren ')' characters are 
supposed to be a part of the code or when they are being used to 
end the code. For the parser this is easy to determine, but 
without it, you now have to go through all the tokens/grammar 
nodes to see where these right-paren characters can appear (i.e. 
string literals, function calls, templates, etc). You could 
implement a simple heuristic where you support as many 
right-paren in your code as there are left-paren characters, 
which will get you most of the way there, but now you've put an 
arbitrary limitation on the code that can appear inside these 
interpolated expressions. The point is, a language solution 
doesn't have this problem. It doesn't need to put any limitations 
on the code, and it doesn't have to come up with a mechanism to 
know when paren characters are or are not apart of the code. This 
problem is non-existent for an implementation inside the compiler.