<div dir="ltr"><div dir="ltr">On Fri, Apr 24, 2020 at 6:25 PM Walter Bright 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 4/23/2020 11:00 PM, Manu wrote:<br>
> I guess this is the key case you need to solve for:<br>
> <br>
>    template T(Args...) {}<br>
>    T!(Tup)     -> T!(0, 1, 2)<br>
>    T!(Tup)...  -> T!0, T!1, T!2<br>
> <br>
> And the parallel expansion disambiguation is also critical:<br>
>    T!(Tup, Tup2...)...  -> T!(0, 3, 4, 5), T!(1, 3, 4, 5), T!(2, 3, 4, 5)<br>
> <br>
> If you can solve those, the rest will probably follow.<br>
<br>
Fair enough. Though there needs to be a rationale as to why those two particuler <br>
cases are needed and critical.<br></blockquote><div><br></div><div>That is essentially the whole thing, simmered down to it's essence. Solve those, we have everything.</div><div>If you can't solve those, we'll have a sea of non-uniformity, edge cases, workarounds, and weird shit; classic D.</div><div><br></div><div>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.</div><div>But this is a clean, uniform, and very efficient design. I would be disappointed to accept anything less.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Also, can you show all the cases where expansion can and can't occur under your proposal?</div><div>These are cases where it must be inhibited:</div><div>1. calling function (because overloads/varargs, risk of hijacking)</div><div>2. template instantiations (because variadic arguments)</div><div>3. UFCS (because overloads + varargs)</div><div>4. array indexing (because overloaded opIndex for N-dimensional arrays)</div><div><br></div><div>We also lose the expansion for static fold.</div><div><br></div><div>Are there more applications that we lose?</div><div><br></div><div>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 :/</div><div>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.</div></div></div>