The state of string interpolation

[Steven Schveighoffer]

On 12/7/18 9:49 PM, H. S. Teoh wrote:
> On Fri, Dec 07, 2018 at 09:29:10PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> But it's not an AliasSeq. It's simply a list of items.
>>
>> for example, I want this to work:
>>
>> writeln(i"a + b = ${a+b}");
>>
>> And this compiles:
>>
>> writeln("a + b = ", a + b);
>>
>> But this does not:
>>
>> writeln(AliasSeq!("a + b = ", a + b));
> [...]
> 
> Hmph.  I forgot about this limitation of compile-time tuples aka
> AliasSeq: you cannot capture expressions this way. :-(
> 
> The best I could come up with was to replicate std.typecons.Tuple:
> 
> 	import std.stdio;
> 	alias AliasSeq(T...) = T;
> 	struct Tuple(T...)
> 	{
> 		T t;
> 		alias t expand;
> 	}
> 	auto func(Args...)(Args args)
> 	{
> 		return Tuple!Args(args);
> 	}

So this is completely different from an AliasSeq. An AliasSeq is a 
compile-time list, and ONLY allows symbols and values known at compile 
time. An expression like "a + b" cannot be aliased.

What your code is doing is making an AliasSeq of *types* and then 
assigning the given values to an instance of those types. That works, 
and is not dissimilar to what I expect the string list to do when used 
on a runtime function.

But we can't have this proposal without that support. So we have to say 
it's not exactly an AliasSeq.

I have a PR on the DIP right now, take a look, would appreciate input: 
https://github.com/jash11/DIPs/pull/3

> 	void main() {
> 		int a=1, b=2;
> 
> 		// Desired effect
> 		writeln("Sum of ", a, " and ", b, " is ", a+b);
> 
> 		// NG: doesn't compile:
> 		//writeln(AliasSeq!("Sum of ", a, " and ", b, " is ", a+b));
> 
> 		// This works (but is ugly)
> 		writeln(func("Sum of ", a, " and ", b, " is ", a+b).expand);
> 	}
> 
> 
> This certainly puts a damper in our proposal. :-(
> 
> 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.

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