I dun a DIP, possibly the best DIP ever

[Manu]

On Fri, Apr 24, 2020 at 6:25 PM Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 4/23/2020 11:00 PM, Manu wrote:
> > I guess this is the key case you need to solve for:
> >
> >    template T(Args...) {}
> >    T!(Tup)     -> T!(0, 1, 2)
> >    T!(Tup)...  -> T!0, T!1, T!2
> >
> > And the parallel expansion disambiguation is also critical:
> >    T!(Tup, Tup2...)...  -> T!(0, 3, 4, 5), T!(1, 3, 4, 5), T!(2, 3, 4, 5)
> >
> > If you can solve those, the rest will probably follow.
>
> Fair enough. Though there needs to be a rationale as to why those two
> particuler
> cases are needed and critical.
>

That is essentially the whole thing, simmered down to it's essence. Solve
those, we have everything.
If you can't solve those, we'll have a sea of non-uniformity, edge cases,
workarounds, and weird shit; classic D.

I haven't had experience with this feature yet; I don't know what's going
to emerge... but the last thing D needs is more weird edge cases.
But this is a clean, uniform, and very efficient design. I would be
disappointed to accept anything less.

I completely understand your motive, it's exactly where I started too. I
couldn't find a way to resolve the ambiguity issues, and I'm not really
interested in proposing a highly compromised design with workarounds to
suit various usage contexts; that's just mental baggage you have to carry
to solve application in all the different usage scenarios.

I'd like you to solve the cases I show above with your proposal. Find a way
to do that, I'm super into your solution. If not, then I'm pretty invested
in my DIP as specced.

Also, can you show all the cases where expansion can and can't occur under
your proposal?
These are cases where it must be inhibited:
1. calling function (because overloads/varargs, risk of hijacking)
2. template instantiations (because variadic arguments)
3. UFCS (because overloads + varargs)
4. array indexing (because overloaded opIndex for N-dimensional arrays)

We also lose the expansion for static fold.

Are there more applications that we lose?

It's possible that it must be inhibited ANYWHERE left of a `.` because to
the right might be a function, and/or because UFCS, we can not allow it due
to risk of hijacking :/
I don't think auto-expand is safely applicable to enough contexts. I really
think the explicit syntax is a better approach, and I'm interested in
seeing how to apply the expand syntax to arrays for uniformity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200424/a5a28f8a/attachment-0001.htm>