The state of string interpolation

[Paul Backus]

On Monday, 10 December 2018 at 20:57:52 UTC, Atila Neves wrote:
> On Monday, 10 December 2018 at 16:55:38 UTC, Paul Backus wrote:
>> On Monday, 10 December 2018 at 10:55:05 UTC, Atila Neves wrote:
>>> Strawman.
>>>
>>> My point isn't that syntax sugar isn't needed, is that in 
>>> this case the problem is easily solved with a library (and 
>>> has been), and doesn't apply to anything except for multiline 
>>> code generation, which is a niche.
>>
>> In languages that support it, string interpolation is used for 
>> many things other than multiline code generation.
>
> I meant compared to std.conv.text. If it fits on one line then 
> `text` is more than fine.

Compare:

     const expected = ...;
     const result = foo(x, y, z);

     // without interpolation
     assert(result == expected,
         text("`foo(", x, ", ", y, ", ", z, ")`: expected `", 
expected, "` but got `", result, "`"));

     // with library interpolation
     assert(result == expected, mixin(interp!
         "`foo($(x), $(y), $(z))`: expected `$(expected)` but got 
`$(result)`"));

     // with built-in interpolation syntax
     assert(result == expected,
         i"`foo($(x), $(y), $(z))`: expected `$(expected)` but got 
`$(result)`".text);

Even for a single-line string, the interpolated version has clear 
advantages.

I'll grant that the difference between interpolation as a library 
and as a language feature is a lot smaller than the difference 
between interpolation and plain-old `text`. So maybe getting 
`interp` into Phobos is a better line of attack than trying to 
sell W&A on new syntax.