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.