<div dir="ltr"><div dir="ltr">On Fri, Apr 24, 2020 at 4:35 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"><br>
There's a lot of merit to the idea of arrays and tuples using a common syntax, <br>
which is what I'm proposing.<br></blockquote><div><br></div><div>Your idea all falls over anywhere it encounters variadic args, or potential for overloads though. Without an explicit expression, the only way forward is to preserve existing D semantics (or it's a radically breaking change), and that will severely narrow the applicability of this proposal.</div><div><br></div><div>Consider this:</div><div><br></div><div>  alias Tup = AliasSeq!(0, 2, 3);</div><div>  void fun(int);<br></div><div>  fun(Tup);  // scalar argument receives tuple, it can expand, so: fun(0), fun(1), fun(2)<br></div><div><br></div><div>Now someone introduces an overload:</div><div>  void fun(int, int, int);</div><div><br></div><div>To the previous expression expanded, but now it found an applicable call and doesn't expand anymore.</div><div>Obviously that's far too dangerous to allow, so; functions MAY have overloads (or just accept var args), and I think that simply means that expansion can never be applied to function arguments.</div><div>That's a HUGE loss, because I do that extremely frequently. Probably more than anything.</div><div><br></div><div>This same principle argument applies to templates which may receive variadic arguments.<br></div><div>It weakens the value in my DIP by a huge amount to forego the explicit syntax designed specifically to handle the resolution of ambiguous expressions.</div><div><br></div><div>This doesn't rule out your proposition that `Tup + 10` can (and probably should) work though. Again, these are not mutually exclusive proposals.</div></div></div>