<div dir="ltr"><div dir="ltr">On Fri, Apr 24, 2020 at 12:20 AM WebFreak001 via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 23 April 2020 at 14:06:03 UTC, Stefan Koch wrote:<br>
> On Thursday, 23 April 2020 at 13:48:54 UTC, Steven <br>
> Schveighoffer wrote:<br>
>><br>
>> No, Foo!(AliasSeq!(1, 2)...)... is equivalent to <br>
>> Foo!(AliasSeq!(1, 2))<br>
>><br>
> In the current implementation it's a parser error.<br>
<br>
I would assume that both<br>
<br>
alias Numbers = AliasSeq!(1, 2);<br>
Foo!(Numbers...)<br>
<br>
and<br>
<br>
Foo!(AliasSeq!(1, 2)...)<br>
<br>
should do the same, no?<br></blockquote><div><br></div><div>Well, they both do nothing.</div><div>You probably mean </div><div><br></div><div>Foo!(Numbers)...</div><div>Foo!(AliasSeq!(1, 2))...</div><div><br></div><div>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.</div><div>Expansion occurs before expression evaluation... and it must, because the expression to evaluate is the result of the expansion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think of something like (expr + Tuple)... as a simple map!(Item <br>
=> expr + Item) - however the compiler automatically finding the <br>
Tuple and the scope of the expression really bugs me the most <br>
here because it feels so subjective.<br>
<br>
Wouldn't some syntax like Tuple->{Tuple + 4} be clearer and <br>
easier to parse for both DMD and static analysis tools? To keep <br>
it as simple as possible it would just reuse the name of the <br>
tuple as item name, but then it's basically a fancy, clear map <br>
syntax, where you exactly control the tuple that's being expanded <br>
and avoid any issues with nested tuples in the expression tree.<br></blockquote><div><br></div><div>What you're describing is something that starts to look like type functions, or a type lambda specifically.</div><div>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!</div><div><br></div><div>> clearer and easier to parse for both DMD</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div></div>