I dun a DIP, possibly the best DIP ever

[Manu]

On Wed, Apr 22, 2020 at 11:50 PM WebFreak001 via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200423/0f9d2966/attachment.htm>