The state of string interpolation...one year later

[Jonathan Marler]

On Sunday, 17 March 2019 at 17:05:46 UTC, Kagamin wrote:
> On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>> CON 3. Performance.  No matter what we do, any library 
>> solution will never be as fast as a language solution.
>
> Must consider the price. Language bloat is not free.

Right, which is why I mentioned we must consider the price 
further down. I know it's a long post though, I don't blame you 
for not reading it all :)

>
>> CON 4. IDE/Editor Support.  A library solution won't be able 
>> to have IDE/Editor support for syntax highlighting, 
>> auto-complete, etc.  When the editor sees an interpolated 
>> string, it will be able to highlight the code inside it just 
>> like normal code.
>
> There's IDE support for format string validation for C and C#.

Which works in some cases.  It can't work in all cases unless 
language support is added.  Still a CON for the library solution.

>
>> CON 5. Full solution requires full copy of lexer/parser.  One 
>> big problem with a library solution is that it will be hard 
>> for a library to delimit interpolated expresions.  For full 
>> support, it will need to have a full implementation of the 
>> compiler's lexer/parser.
>
> The interpolated string syntax is as complex as the whole D 
> language? That sounds bad. AFAIK IDEs don't even support UFCS 
> yet even though it should be simple.

The full solution requires a full copy of the lexer/parser, but 
the syntax for interpolated strings is just allowing string 
literals to be prefixed with the letter 'i'.  You've confused the 
syntax for interpolated strings with the complexity of arbitrary 
D expression inside them.  If you want to be able to write any 
code inside those expressions, then you need the full parser 
lexer to parse it.  A language solution already has access to 
this but a library implementation will need to either copy the 
full implementation, or make compromises in what it can support.

>
>> 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 :) And 
it's a contrived example to demonstrate an example that would be 
hard for a library to parse.  In reality you wouldn't write it 
that way (hence why I called it "contrived").  With full 
interpolation support you would write it like this:

i"$(i)) entry $(array[i])"