April 15, 2017
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.
April 15, 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.
April 15, 2017
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.
April 15, 2017
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.
April 15, 2017
On Saturday, 15 April 2017 at 23:11:42 UTC, Stanislav Blinov wrote:
> How about... it removes an import or two?

It doesn't actually remove the dependency, it is just syntax sugar over it (there is precedent for this in the language, the pow operator calls a Phobos function, but it means you don't actually gain decoupling of modules).
April 16, 2017
On Saturday, 15 April 2017 at 23:58:18 UTC, Adam D. Ruppe wrote:
> On Saturday, 15 April 2017 at 23:11:42 UTC, Stanislav Blinov wrote:
>> How about... it removes an import or two?
>
> It doesn't actually remove the dependency, it is just syntax sugar over it (there is precedent for this in the language, the pow operator calls a Phobos function, but it means you don't actually gain decoupling of modules).

As presented, it doesn't. But it can be implemented in a way that it does. The compiler is capable of conversions without ever needing std.conv, and if custom .toString() is required, it will already be available anyway.

As to the importance of this, I can only suggest measuring the code, both public and your own.
Constructing a string out of variable values without any special formatting is, in my experience, a very common operation. Do importing a module *just* to build a mixin without building a mixin to build that mixin, static error message or a result for a script; CTFE evaluating a good deal of general-purpose code for a trivial use case have to be common as well?
April 16, 2017
On 4/15/17 10:04 PM, Jonas Drewsen wrote:
> Hi all
>
>   I've been wanting to have support for interpolated strings in D for
> some time now that will allow you to write e.g.:
>
> auto a = 7;
> writeln( $"{a} times 3 is {a*3}" );
>
> Code speaks louder that words so I've made a PR that adds this support
> to ddmd as a RFC [1].
>
> The compiler will basically lower the $"..." string to a mixin that
> concatenates
> the expression parts of the (inside the {}) and the plain text parts.
>

Just a quick comment - I would be more interested if the string interpolation was extendable by the user. A simple path would be to make string interpolation produce AliasSeq of interleaved pieces of string with the arguments.

So in your example
writeln($"{a} times 3 is {a*3}")
lowers to
writeln(AliasSeq!(a, " times 3 is ", a*3));
which is basically
writeln(a, " times 3 is ", a*3);

but notice how depending on the function it can be used for other things such as DSLs.

> I do recognize that this is not part of the 2017 H1 plan but I also
> believe such smaller improvements added regularly can make the language
> both more productive and attractive.
>
> In case this addition gets a thumbs up I will of course improve test
> coverage and any needed quality of implementation.
>
> [1] https://github.com/dlang/dmd/pull/6703
>


---
Dmitry Olshansky
April 16, 2017
On Sat, 2017-04-15 at 21:48 +0000, cym13 via Digitalmars-d wrote:
> […]
> 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.

Python now has string interpolation, f-strings.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

April 16, 2017
On 2017-04-15 22:04, Jonas Drewsen wrote:
> Hi all
>
>    I've been wanting to have support for interpolated strings in D for
> some time now that will allow you to write e.g.:
>
> auto a = 7;
> writeln( $"{a} times 3 is {a*3}" );
>
> Code speaks louder that words so I've made a PR that adds this support
> to ddmd as a RFC [1].
>
> The compiler will basically lower the $"..." string to a mixin that
> concatenates
> the expression parts of the (inside the {}) and the plain text parts.
>
> I do recognize that this is not part of the 2017 H1 plan but I also
> believe such smaller improvements added regularly can make the language
> both more productive and attractive.
>
> In case this addition gets a thumbs up I will of course improve test
> coverage and any needed quality of implementation.

My initial reaction is that this is something that can be implemented as library code if the language would have support for AST macros.

On the other hand, this is something I would like to have in the language or the standard library.

-- 
/Jacob Carlborg
April 16, 2017
On 04/15/2017 04:35 PM, crimaniak wrote:
> On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
>> The compiler will basically lower the $"..." string to a mixin that
>> concatenates
>> the expression parts of the (inside the {}) and the plain text parts.
> It's easy implementable as a library (see
> https://github.com/Abscissa/scriptlike#string-interpolation) so it does
> not seem like a good idea to modify the language, only to change
> interp!"" to $"".

Yea, and note, I'm still open to the idea of better names than "interp". I'm still not entirely happy with that name. I'm even half-tempted to use "_".

The only one problem I've found with doing it in library though: Far as I could tell, it seems to require the caller uses string mixins, which makes actually using it a little uglier and more verbose than I would like. Maybe I'm overlooking something obvious, but I haven't been able to find a way to change it to either a template mixin or even just a plain template without sacrificing to whole point of interpolated strings: specifying the arguments 100% inline.

What I think would be ideal is a language enhancement to allow "interp" to do its job without the extra syntactical noise. That would not only give us good interpolates strings, but would likely have other applications as well.