I really wish that D had string interpolation, and I can see that a ton of other people also do. String interpolation has been brought up before, but it has been ignored/put down every time. Jonathan Marler even created a Pull Request (https://github.com/dlang/dmd/pull/7988) to add this feature, but he ended up closing it because it was getting nowhere. The excuse that keeps being given for not adding this feature is something along the lines of "There are ways to work around this, so it is unnecessary to add it". If this is the case, then why do people keep on requesting it again and again? Here are just some cases of other people asking for string interpolation:

- https://forum.dlang.org/thread/c2q7dt$67t$1@digitaldaemon.com
- https://forum.dlang.org/thread/qpuxtedsiowayrhgyell@forum.dlang.org
- https://forum.dlang.org/thread/ncwpezwlgeajdrigegee@forum.dlang.org
And there are 2 closed PRs for this:
- https://github.com/dlang/dmd/pull/6703
- https://github.com/dlang/dmd/pull/7988

In my opinion, having a sizable amount of people request a feature (about 100 out of 280 as of The State of D Survey [https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig]) is a good enough to realize that maybe we should start thinking of adding it to the language.

I understand that this may involve a DIP process, which takes time. Therefore I am willing to offer up $100 to someone if they are willing to go through the DIP process for string interpolation.

And please don't mention Phobos' sorry excuse for string interpolation:
"a is: %s, b is: %s, sum is %s.".format(a, b, a + b)
Is no better than
"a is: "~a.to!string~"b is: "~b.to!string~" and the sum is: "~(a+b).to!string~"."

This is just so much more readable, and maintainable:
"a is: ${a}, b is: ${b}, and the sum is: ${a+b}."

And, it gets even more readable with syntax highlighting: https://i.imgur.com/Bz79vtV.png

So please, what I am asking is that we start to *seriously* consider adding string interpolation to D. Thanks for taking the time to read this!

On Thu, Dec 06, 2018 at 12:10:56AM +0000, o via Digitalmars-d wrote:
> I really wish that D had string interpolation, and I can see that a ton of other people also do. String interpolation has been brought up before, but it has been ignored/put down every time. Jonathan Marler even created a Pull Request (https://github.com/dlang/dmd/pull/7988) to add this feature, but he ended up closing it because it was getting nowhere. The excuse that keeps being given for not adding this feature is something along the lines of "There are ways to work around this, so it is unnecessary to add it". If this is the case, then why do people keep on requesting it again and again?
[...]

Why can't this be added to to code.dlang.org as a library / dub package / whatever?

Heck, I'd even use it.  Getting anything into Phobos these days is an uphill battle, and not the kind I have the time (or patience) to fight.

In fact, I'd even *implement* it, if someone else hasn't already done it.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

On Thursday, 6 December 2018 at 00:20:53 UTC, H. S. Teoh wrote:
> Why can't this be added to to code.dlang.org as a library / dub package / whatever?

Library things cannot access the local scope of the string unless you mixin.

So

mixin(interp!"foo #{a}");

is doable as a library (and I know Nick Sabalusky's scriptlike has it, probably among others), but

string b = "foo #{a}";

is only doable as a language feature.

On Thursday, 6 December 2018 at 00:32:48 UTC, Adam D. Ruppe wrote:
> string b = "foo #{a}";
>
> is only doable as a language feature.

Exactly. This is what we need. No messing around with templates or mixins.

On Thu, 06 Dec 2018 00:10:56 +0000, o wrote:
> And please don't mention Phobos' sorry excuse for string interpolation:
> "a is: %s, b is: %s, sum is %s.".format(a, b, a + b)
> Is no better than "a is: "~a.to!string~"b is: "~b.to!string~" and the
> sum is: "~(a+b).to!string~"."

I mean, let's not be hyperbolic. Or contemptuous. format() is a lot more readable than a bunch of concatenation for a lot of things. It gives you a coherent view of the structure of the string as a whole. As a tradeoff, it's harder to see the relationship between the format specifiers and the parameters.

String interpolation gets rid of that tradeoff.

However, that would also force druntime to include formatting code that it currently lacks. It's very likely that this would have some inconsistencies with std.conv. Like, the most straightforward way to make this work is to have a runtime function taking variadic arguments:

    string _d_stringinterpc(...);
    wstring _d_stringinterpw(...);
    dstring _d_stringinterpd(...);

That would allow a pluggable approach, which allows for the maximum amount of compatibility.

So you write:

    auto bar = "hello world".lazyReplace('l', 'p');
    writeln("foo ${bar}");

This compiles down to:

    writeln(_d_stringinterpc("foo ", bar));

And it prints:

    foo scratch.LazyReplacementRange!(immutable(char),
string).LazyReplacementRange

lazyReplace returns a LazyReplacementRange, which doesn't define toString(). Its corresponding TypeInfo_Struct doesn't have a xtoString function pointer set, so we can't convert it to a string by calling .toString() on it (even indirectly through reflection). We can't list its properties and fields at runtime, so we can't iterate through it like std.format would. We can't even assemble a toString() that looks like the default for structs in std.conv.

The only thing we have available is the name of the type.

In 2007, this would have worked.

----

Okay, it's bad to use that sort of runtime function. What about putting a template inside object.d?

That would require us to put std.conv and std.format into object.d. It wouldn't be even remotely pluggable.

This isn't an issue in most languages. Most languages tie their standard libraries to their compilers. D maintains a greater separation than normal, in part because of the Tango / Phobos separation.

On Thursday, 6 December 2018 at 02:14:12 UTC, Neia Neutuladh wrote:
> However, that would also force druntime to include formatting code that it currently lacks.

Not necessarily. There is precedent in the language for a built-in feature actually lowering to a Phobos call: the ** operator is translated to std.math.pow.

The interpolate thing could very well be translated to a call to std.conv.text.

wow I did not know that.
P.S. ** should be ^^ right?

On Thu, Dec 6, 2018 at 3:55 AM Adam D. Ruppe via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 6 December 2018 at 02:14:12 UTC, Neia Neutuladh wrote:
> > However, that would also force druntime to include formatting code that it currently lacks.
>
> Not necessarily. There is precedent in the language for a built-in feature actually lowering to a Phobos call: the ** operator is translated to std.math.pow.
>
> The interpolate thing could very well be translated to a call to std.conv.text.
>

On Thursday, 6 December 2018 at 02:14:12 UTC, Neia Neutuladh wrote:
> However, that would also force druntime to include formatting code that it currently lacks.

Jonathan Marler's implementation [1] has a really nice approach of lowering interpolated strings to tuples. You can pass it to variadic functions like `writeln` or `text` and bring your own formatting / memory allocation schemes, giving better performance and flexibility.

[1] https://github.com/dlang/dmd/pull/7988

would it be possible to have some kind of eponymous mixin templates in the language?
I'd imagine it to look something like this:

````
import std.stdio;

mixin template interp(string S) {
    mixin interp = S; //some fancy code to replace ${_var_} with content of _var_
}

void main() {
    int a = 5;
    string b = interp!"hello ${a} world";
}
```

On Thursday, 6 December 2018 at 09:01:03 UTC, Dennis wrote:
> Jonathan Marler's implementation [1] has a really nice approach of lowering interpolated strings to tuples.

Yes, yes, yes, I like that a lot. I think that's the way to do it if D is ever to get these.

I propose that we all either

1) drop the idea

or

2) unite around that proposal and try to push it through.