On Saturday, 8 December 2018 at 02:49:46 UTC, H. S. Teoh wrote:
> How does Marler's implementation behave? Does it capture expressions? If it does, we have good news (but we'll have to document this clearly, since it would be unprecedented in the current language).  If not, we'll have to think more carefully about how to implement this.
>
>
> T

Yes it captures expressions. I've gone ahead and reopened and rebased my PR so that people can try it out.  Once you build it, make sure to include the "-transition=interpolate" flag to enable string interpolation.  And take a look at the "test/runnable/istring.d" for examples.

On Thursday, 6 December 2018 at 00:10:56 UTC, o wrote:
> I really wish that D had string interpolation

I program in languages which have string interpolation but hardly use it.

Probably there is a better way of doing things if you're using it a lot.

For example for HTML there is hyperscript.

On Saturday, 8 December 2018 at 03:15:47 UTC, Steven Schveighoffer wrote:
> Really, I just wanted it to expand into "as if you typed all those things individually separated by commas".

Sounds like a "Variadic Argument List of Strings" to me.

Mike

On Saturday, 8 December 2018 at 05:55:58 UTC, Mike Franklin wrote:
> On Saturday, 8 December 2018 at 03:15:47 UTC, Steven Schveighoffer wrote:
>> Really, I just wanted it to expand into "as if you typed all those things individually separated by commas".
>
> Sounds like a "Variadic Argument List of Strings" to me.
>
> Mike

That's almost exactly what it is, except it's not just strings.

To anyone who's still confused by this, I cannot recommend strongly enough the "Compile-Time Sequences" article on dlang.org. [1] It explains very clearly what these "argument sequences" are and how they work, with copious examples.

[1] https://dlang.org/articles/ctarguments.html

On Saturday, 8 December 2018 at 03:04:35 UTC, Steven Schveighoffer wrote:
> I'm yet unclear yet whether the implementation behaves that way, but if it doesn't we should just change it so it does. But he has said (a bit ambiguously) that it does do expressions (comment in that PR).
>
> If we can't get arbitrary expressions to work at runtime, then this proposal is no good.
>
> -Steve

It definitely does do expressions. The implementation just calls "parseExpression" for stuff inside '$(…)'.

int fun(int n) { return n; }

string hal = "HAL";
assert(i"$(hal) $((() => 1_000)() * 8 + fun(1_000))".text == "HAL 9000");

On 2018-12-07 04:29, Steven Schveighoffer wrote:

> vibe.d does string interpolation in it's diet templates, but the rub is that you have to pass in an alias to the variables you want to be visible in the interpolation. So it requires a very un-DRY solution, and also doesn't work with arbitrary expressions.

I haven't used the diet templates but I have used views, the corresponding system, in Ruby on Rails quite a lot. There it's not required to pass in the variables to the view/template. But in my experience it's best to create an explicit object that will contain all the data you need from the view. This usually leads to better code than passing in a bunch of different modules, which you usually end up adding view specific methods to. Following this module you would only need to pass in one object/struct value.

-- 
/Jacob Carlborg

On 2018-12-07 01:43, Mike Franklin wrote:

> I know I'm just thinking out loud and not contributing much, but I can't help but feel that there's something common in all these ideas that just hasn't been identified yet.  And no, Jacob, not AST macros (Actually, that would probably do it, but I think we've already been there) :D

It's quite annoying to see so many suggestions for new language features and existing highly specialized features that could be solved with AST macros instead of new language features.

-- 
/Jacob Carlborg

On Saturday, 8 December 2018 at 12:23:28 UTC, Jacob Carlborg wrote:
> It's quite annoying to see so many suggestions for new language features and existing highly specialized features that could be solved with AST macros instead of new language features.

It quite clear from walter that it will be a snowball chance in hell that AST macros will be accepted in the language. The AST macros DIP need to have overwhelming arguments and evidence in order to penetrate the steel fortress that is armed with artillery, militarily grade assault-rifles and helicopters that is Walter. Which from looking at the current 50dip, it does not have.

Unless you are going to committed to a writing such a dip, I think it is safe to say AST macros will never going to be implemented.

On Saturday, 8 December 2018 at 02:29:10 UTC, Steven Schveighoffer wrote:
> this compiles:
>
> writeln("a + b = ", a + b);
>
> But this does not:
>
> writeln(AliasSeq!("a + b = ", a + b));
>
> -Steve

As Paul Backus brought up in a PR, you can use `std.typecons.tuple`s instead, to use expressions. Example:

auto foo = tuple(i"a + b = $(a+b)");

On Thursday, 6 December 2018 at 00:32:48 UTC, Adam D. Ruppe wrote:
> 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.

I am referring to this post, because it is the first mentioning the mixin way in this thread:

          Why is mixin() not allowed in UFCS?


it may become way nicer, and with an alias i=interp; we would have

=>

writeln(i!"foo #{a}".mixin) // which is not to far away from writeln(i"foo #{a}")
or:
i!"foo #{a}".mixin.writeln;