Interpolated strings

[cym13 via Digitalmars-d]

On Saturday, 15 April 2017 at 23:11:42 UTC, Stanislav Blinov 
wrote:
> On Saturday, 15 April 2017 at 21:38:24 UTC, cym13 wrote:
>> On Saturday, 15 April 2017 at 20:20:49 UTC, Stanislav Blinov 
>> wrote:
>>> On Saturday, 15 April 2017 at 20:12:41 UTC, cym13 wrote:
>>>> On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen 
>>>> wrote:
>>>
>>>> This has been proposed before, and I still don't see the 
>>>> added value compared to:
>>>>
>>>>     auto a=7;
>>>>     writeln(a, " times 3 is ", a*3);
>>>>
>>>> besides adding compiler complexity, language complexity and 
>>>> parsing complexity which leaves room for more bugs to be 
>>>> invented. I'm a bit more harsh than I could be, but if this 
>>>> simple question has no clear answer I don't see why it sould 
>>>> make it into the language.
>>>
>>> Try a different context:
>>>
>>> auto a = 7;
>>>
>>> import std.format;
>>> auto str = format("%s times 3 is %s", a, a*3);
>>>
>>> //or
>>>
>>> import std.conv;
>>> auto str = text(a, " times 3 is ", a*3);
>>>
>>> //or
>>>
>>> auto str = $"{a} times 3 is {a*3}";
>>
>> This tells me nothing. What value does it add really? Do we 
>> need yet another way to make a damn string? There is value in 
>> having a clear, unique interface. I know it's nowhere near 
>> unique right now but that only more reasons not to add yet 
>> another method to do what can already be done with 3 (!) more 
>> keystrokes.
>
> How about... it removes an import or two? Roughly 41.5% of 
> Phobos (module-wise) depends on either format() or text(). And 
> I didn't even include the ~ and .stringofs in the search. Quick 
> visual scan suggests that a good portion of that could be 
> replaced with the proposed solution, removing the dependency. 
> Talk about "parsing complexity"...
> You have a peculiar way of asking for a clear answer. There are 
> ways to vent frustration without inflicting it on others, you 
> know.

Removing imports is a good point, the first concrete one to be 
mentionned. I'm not sure it matters that much though as I think 
those imports are generic enough that I believe they would be 
imported anyway, but it's a real point.

For parsing complexity I'm not talking about quantity actually, 
maybe I should say "parser complexity" instead.

There again, all I want is a solid rational. This is far from 
being a little change, if the only things it brings are "looks 
nicer" and "one less import in some cases" I'm sure you'll agree 
that the case is pretty thin. It won't ever be my call but bear 
with me challenging the idea. I'm not venting frustration, and 
I'm not being insulting or anything, just clear and explicit with 
what problem I see.