On Thursday, 23 April 2020 at 14:06:03 UTC, Stefan Koch wrote:
> On Thursday, 23 April 2020 at 13:48:54 UTC, Steven
> Schveighoffer wrote:
>>
>> No, Foo!(AliasSeq!(1, 2)...)... is equivalent to
>> Foo!(AliasSeq!(1, 2))
>>
> In the current implementation it's a parser error.
I would assume that both
alias Numbers = AliasSeq!(1, 2);
Foo!(Numbers...)
and
Foo!(AliasSeq!(1, 2)...)
should do the same, no?
Well, they both do nothing.
You probably mean
Foo!(Numbers)...
Foo!(AliasSeq!(1, 2))...
But even then, no; there's no tuple to expand in that second statement. What there is, is a template instantiation, and it _resolves_ to a tuple, but the current spec doesn't tunnel into post-evaluation tuples like that. If it did, I think it would be very unwieldy.
Expansion occurs before expression evaluation... and it must, because the expression to evaluate is the result of the expansion.
I think of something like (expr + Tuple)... as a simple map!(Item
=> expr + Item) - however the compiler automatically finding the
Tuple and the scope of the expression really bugs me the most
here because it feels so subjective.
Wouldn't some syntax like Tuple->{Tuple + 4} be clearer and
easier to parse for both DMD and static analysis tools? To keep
it as simple as possible it would just reuse the name of the
tuple as item name, but then it's basically a fancy, clear map
syntax, where you exactly control the tuple that's being expanded
and avoid any issues with nested tuples in the expression tree.
What you're describing is something that starts to look like type functions, or a type lambda specifically.
I'm all for type functions, but that's not what this DIP is. I'm in full support of a type functions DIP though!
> clearer and easier to parse for both DMD
This has been surprisingly easy to implement. It's trivial to parse, and semantic has been totally self-contained. The complexity we've discovered is pretty much 100% concerning the moment that expansion is applied vs semantic being run. Expansion must apply before the expression evaluation, because the expansion affects the expression to be evaluated.