<div dir="ltr"><div dir="ltr">On Wed, Apr 22, 2020 at 11:50 PM 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 Wednesday, 22 April 2020 at 12:19:25 UTC, rikki cattermole <br>
wrote:<br>
> Change it to something like .unpackSequence instead of ... and <br>
> I would be happy.<br>
<br>
I'm for some other thing than ... too, in C++ it's a quite bad <br>
syntax</blockquote><div><br></div><div>Negative, it's the single best thing that happened to C++ in almost 2 decades.</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"> and it can become very ugly to maintain with all the <br>
different combinations you could use it with from a compiler <br>
viewpoint.</blockquote><div><br></div><div>Actually, the implementation turned out to be 100x more simple and sane than I expected going in.</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"> Additionally if you do miss some combinations or allow <br>
more complex operators it will quickly become a mess of "why does <br>
this compile but why doesn't this compile" or "why does this do <br>
something different"<br></blockquote><div><br></div><div>If you're asking the question "why does this do something different", then you exposed an edge case that should be considered a bug.<br></div><div>This has uniform application.</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'm especially not a fan of allowing all of<br>
(Tup*10)...  -->  ( Tup[0]*10, Tup[1]*10, ... , Tup[$-1]*10 )<br>
and<br>
(Tup1*Tup2)...<br>
and<br>
myArr[Tup + 1]... -> myArr[Tup[0] + 1], myArr[Tup[1] + 1], <br>
myArr[Tup[2] + 1]<br></blockquote><div><br></div><div>I don't understand your criticism... this is exactly the point of the DIP.</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">
would this be valid:<br>
f!T...(x)<br>
or rather this?<br>
f!T(x)...<br></blockquote><div><br></div><div>Well they're both syntactically possible, but the first one is a nonsense expression; you're trying to call a TupleExp, which I expect would be a compile error.</div><div>The second is a tremendously useful pattern.</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">
what does (cast(Tup)x)... evaluate to?<br></blockquote><div><br></div><div>  (cast(Tup[0])x, 

cast(Tup[1])x, 

cast(Tup[2])x, ...)<br></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">
is f(Tup) and f(Tup...) now doing the same thing?<br></blockquote><div><br></div><div>Yes, the identity expansion is a no-op. This is perfectly reasonable and a very nice property of the DIP.</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">
if<br>
f(Items.x...)<br>
works then what about<br>
f(Items.MemberTup...) ?<br></blockquote><div><br></div><div>We have encountered this, and defining this is the only WIP detail I'm aware of.</div><div>If we follow normal D rules where tuples in tuples flatten, then the natural result with no special-case intervention is:</div><div>  f( Items[0].MemberTup[0], 

Items[0].MemberTup[1], 

Items[1].MemberTup[0], 

Items[1].MemberTup[1], ... )</div><div><br></div><div>I'm not sure that's particularly useful, but that's what naturally falls from D's tuple auto-expansion rules.</div><div>We're discussing this case, and if breaking from the natural semantics to implement a special case is worth the complexity in the spec. My feeling is that it is not worth a special-case in the spec, and the (probably not useful) expansion I show above would be the natural language rule.</div></div></div>