The state of string interpolation...one year later

[Nick Treleaven]

On Sunday, 17 March 2019 at 06:01:35 UTC, Jonathan Marler wrote:
>     text("a is", a, ", b is ", b, " and the sum is: ", a + b)
>
> Ironically, his example had a mistake, but it was hard to
> notice.

Maybe he wrote that on the forum. In a text editor syntax 
highlighting would make the mistake clearer, but it can still 
happen. The interpolated syntax is definitely clearer.

I think interpolated strings as a language feature is 
justifiable, but that a mixin solution can work with some small 
more general changes to the language, and that these changes are 
both simpler to support and more useful and flexible.

> CON 1. The syntax is "not nice".  This defeats the entire point
> of interpolated strings.

What about `$ident!targs(args)` being sugar for 
`mixin(ident!targs(args))`? Then we can have a function template 
in object.d invoked as:

$iStr!"v = $v"
becomes:
mixin(iStr!"v = $v")

> With library solutions,
> you can't point syntax errors inside interpolated strings to
> source locations.  That information is not available to the
> language.  When you get a string, you don't know where each
> character inside that string originated from, only the compiler
> knows that.

Yes, but the language could support a way to get the file and 
line from template alias arguments inside the template. So at 
least the starting line of the string literal could be known and 
given in an error message.

> CON 3. Performance.  No matter what we do, any library solution
> will never be as fast as a language solution.

True, but what matters is whether a library solution is fast 
enough. If dmd isn't currently then perhaps the CTFE rewrite will 
be.

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

The editor has to be updated for interpolated syntax, so it could 
just as easily be updated to recognise invocation of $iStr if 
iStr was in object.d.

> The library solution needs to parse that interpolated string
> but needs to know that the right paren at `")"` is actually
> just a string literal inside the expression and not a right
> paren to delimit the end of the expression.  This is a
> contrived example, but if you have anything less than a full
> lexer/parser then developers are going to have a hard time
> being able to know what can and can't go inside an interpolated
> expression.

Good point, but I think banning all string delimiters `'" is a 
reasonable and easy to understand restriction. It's good to 
discourage people from putting complex expressions inside 
strings, and this also makes iStr editor highlighting easier to 
implement vs the unrestricted language solution (which could also 
be restricted).

> That being said, I consider the implementation
> and complexity it adds to be quite minimal (see the PR for more
> details). As for the usefullness, I can say personally I would
> use this feature to replace almost all my usages of
> writefln/format and writeln which would be a big shift for my
> projects.  Instead of:
>
> writefln("My name is %s and my age is %s and my favorite hex is
> %s", name, age, favnum);

Actually this should be `writefln!"My name is..."(name, ...)`. 
Formatting can be more efficient if the format string is known at 
compile-time.

> I will be writing:
>
> writeln(i"My name is $name and my age is $age and my favorite
> hex $(favnum.formatHex)");

Does formatHex exist?

>      return text(iq{
>         $returnType $name($type left, $type right)
>         {
>             return cast($returnType)(left $op right);
>         }
>     });

Here there are advantages to the $iStr solution vs your 
implementation. First I would have two mixin functions, iSeq to 
do what you want, and iStr which includes the call to 
std.conv.text:

1. iStr doesn't need to import std.conv.text, which is a very 
common case. Having to import `text` explicitly would often make 
me avoid using the interpolated string feature and use existing 
string syntax instead. (A different language implementation could 
expose text as a property of the interpolated string though).

2. The iStr template gets the string literal passed at compile 
time,
so the length is available for buffer pre-allocation without 
summing the string fragment lengths at runtime. (A different 
language implementation could expose the original string length 
as an enum, then text, writef and format can take advantage of 
it).