Interpolated strings

cym13 via Digitalmars-d digitalmars-d at puremagic.com
Sat Apr 15 14:48:27 PDT 2017


On Saturday, 15 April 2017 at 20:45:23 UTC, Jonas Drewsen 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}";
>
> Yes this is a very basic lowering. The value comes from the 
> fact (assumption?) that this pattern of constructing a string 
> from a mix of strings and expressions is very common. The value 
> of a feature could be described as
>
> usage * productivity_improvement = feature_value
>
> So while the productivity_improvement may be modest the usage 
> is high enough to give a high feature_value and justify the 
> addition. A sign of this is the number of other popular 
> languages supporting this feature (not arguing for just copy 
> other languages but it is still an indicator). Unfortunately I 
> have no hard data for these numbers.

There is a very big hole in your equation. It's more like:

feature_value = usage * productivity_improvement - 
(development_cost + maintainance cost)

also it's worth noting that the productivity improvement is 
weighed down by the time needed to learn the new way, to 
understand other people's code that use yet another way to do 
things, to sift through code to find bugs...

I'm not saying the end value isn't positive, maybe it is. I just 
don't see how right now.

Just an anecdote: I often do security code reviews, that's my 
thing. I work with a lot of languages in that context, and I hate 
having to audit perl or ruby code. It's not because they're bad 
languages, but there is just so many ways to build strings and so 
many ways to execute shell code that finding them all in the code 
to check them is a nightmare. In python on the contrary there is 
a small set of functions that you can use for subprocessing. 
Besides they are all functions so even if they're different the 
structure is alike. This makes it *so* much easier. I want to be 
able to find bugs easily. I want D to be like python on that 
part. Not perl. Not ruby.


More information about the Digitalmars-d mailing list