Interpolated strings

[Patrick Schluter via Digitalmars-d]

On Wednesday, 19 April 2017 at 13:04:08 UTC, Jonathan Marler 
wrote:
> On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
>> On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
>> wrote:
>>
> I can think of 3 reasons.
>
> 1. Requires GC.
>
> NOTE: I believe that most applcations should use GC memory, 
> that being said, library code has to be nogc wherever it can if 
> it wants to be used by nogc apps, so this solution is unusable 
> in alot of library code.
>
> 2. It's verbose.  Jonas provided a good example of why and he 
> makes a good point that your example only has 1 formatted 
> argument and this problem gets much worse with multiple.
>
> 3. The biggest reason I wouldn't use this solution because it 
> uses string composition.  String composition wastes memory and 
> memory management cycles.  And when I say "waste" what I mean 
> is, the use is unnecessary.  In general composition is a 
> powerful tool because it allows you to easily overload and 
> abstract and add new functionality, however, it requires 
> runtime overhead.  This is the reason that the 
> toString(delegate) was created to replace the composable 
> toString paradigm.  It's also the reason that string formatting 
> exists at all.
>
> To summarize:
>
> // requires GC, too verbose, uses string composition which 
> wastes heap resources
> writeln("The date is " ~ format("%04d", year));
>
> // efficient, but format string and args can get out of sync.
> writefln("the date is %04d", year);
>
> //
> writefln($"the date is {year:04d}");
>
> If string interpolation gets reduced to the 2nd case, then it 
> will have the same efficiency and solve a problem.  Whether 
> that problem justifies the change is up for debate, but I think 
> it *might be*.

As a string interpolation sceptic I have to admit that I found 
one application of that concept that is probably much better than 
the current C derived format strings: Internationalisation.

     dates["en"] = "The date is %2$02d-%1$02d-%3$04d";
     dates["fr"] = "La date est %1$02d-%2$02d-%3$04d";

     writeln(format(dates[lan], day, month, year));

with interpolation we have

     dates["en"] = $"The date is 
{month:%02d}-{day:02d}-{year:04d}";
     dates["fr"] = $"La date est 
{day:%02d}/{month:%02d}/{year:04d}";

which is a little bit easier to read than positional format 
specifiers, which have the added backdraw (at least in C, I don't 
know for D) that they are an none or ALL thing. When you need 
them, you have to put them an all format specifiers.
This said, the interpolation has in that case a big drawback, 
i.e. that they "export" the variable names outside of the scope 
they are defined in. That's a thing that is often required for 
I10N, that the strings are defined in a separate file or module 
and selectively imported (at runtime).