On Wednesday, 22 April 2020 at 12:19:25 UTC, rikki cattermole
wrote:
> Change it to something like .unpackSequence instead of ... and
> I would be happy.
I'm for some other thing than ... too, in C++ it's a quite bad
syntax
Negative, it's the single best thing that happened to C++ in almost 2 decades.
and it can become very ugly to maintain with all the
different combinations you could use it with from a compiler
viewpoint.
Actually, the implementation turned out to be 100x more simple and sane than I expected going in.
Additionally if you do miss some combinations or allow
more complex operators it will quickly become a mess of "why does
this compile but why doesn't this compile" or "why does this do
something different"
If you're asking the question "why does this do something different", then you exposed an edge case that should be considered a bug.
This has uniform application.
I'm especially not a fan of allowing all of
(Tup*10)... --> ( Tup[0]*10, Tup[1]*10, ... , Tup[$-1]*10 )
and
(Tup1*Tup2)...
and
myArr[Tup + 1]... -> myArr[Tup[0] + 1], myArr[Tup[1] + 1],
myArr[Tup[2] + 1]
I don't understand your criticism... this is exactly the point of the DIP.
would this be valid:
f!T...(x)
or rather this?
f!T(x)...
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.
The second is a tremendously useful pattern.
what does (cast(Tup)x)... evaluate to?
(cast(Tup[0])x,
cast(Tup[1])x,
cast(Tup[2])x, ...)
is f(Tup) and f(Tup...) now doing the same thing?
Yes, the identity expansion is a no-op. This is perfectly reasonable and a very nice property of the DIP.
if
f(Items.x...)
works then what about
f(Items.MemberTup...) ?
We have encountered this, and defining this is the only WIP detail I'm aware of.
If we follow normal D rules where tuples in tuples flatten, then the natural result with no special-case intervention is:
f( Items[0].MemberTup[0],
Items[0].MemberTup[1],
Items[1].MemberTup[0],
Items[1].MemberTup[1], ... )
I'm not sure that's particularly useful, but that's what naturally falls from D's tuple auto-expansion rules.
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.