<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Apr 2016, at 20:25, Justin Jia &lt;<a href="mailto:justin.jia.developer@gmail.com" class="">justin.jia.developer@gmail.com</a>&gt; wrote:</div><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">Cons of removing variadic functions:</div><div class="">1. More verbose syntax.&nbsp;</div><div class="">2. Break old code.&nbsp;</div></div></div></blockquote><div><br class=""></div><div>The verbosity is only two characters (square brackets), and it needn’t break old code:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>Before:<span class="Apple-tab-span" style="white-space:pre">        </span>func myFunc(values:Foo…)</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>After:<span class="Apple-tab-span" style="white-space:pre">        </span>func myFunc(values:[Foo])</font></div><div><font face="Monaco" class=""><br class=""></font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>Before:<span class="Apple-tab-span" style="white-space:pre">        </span>myFunc(foo, bar, baz)</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>After:<span class="Apple-tab-span" style="white-space:pre">        </span>myFunc([foo, bar, baz])</font></div><div><br class=""></div><div>Currently variadic functions just produce an array of arguments anyway, so simply translating call-sites to pass in an array guarantees compatibility.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">On Apr 19, 2016, at 10:54 AM, Haravikk &lt;<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 19 Apr 2016, at 17:51, Vladimir.S &lt;<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>&gt; wrote:</div><div class=""><br class="">I.e. the question is *if we want/need to be able to pass array to existed variadic function*. Not about removing the variadic feature("removing" is offtop for this poposal, as I understand)<br class=""></div></blockquote></div><br class=""><div class="">I’d say it’s on-topic, as removing variadic functions would eliminate the problem entirely, so if it is considered a better alternative then there would be no need to have an additional means of calling them with an array of arguments.</div><div class=""><br class=""></div><div class="">Personally the way I see it comes down to variadic functions is this:</div><div class=""><br class=""></div><div class=""><b class="">Pros</b>:</div><div class=""><ul class="MailOutline"><li class="">Slightly cleaner syntax at call-site.</li><li class="">Possibly optimisations unavailable to Array passing?</li></ul><div class=""><br class=""></div></div><div class=""><b class="">Cons</b>:</div><div class=""><ul class="MailOutline"><li class="">Doesn’t do anything that passing an array directly can’t.</li><li class="">Passing an array is actually slightly more flexible (can dynamically pass more or less arguments as required at the call site).</li><li class="">Less explicit type at call site; gives the appearance of passing instance(s) of Foo, rather than one instance of [Foo], can lead to ambiguity with overloaded functions.</li><li class="">Extra syntax to support (enabling array passing would be more code required to support this feature)</li></ul><div class=""><br class=""></div></div><div class="">I’d also argue that variadic functions increase the learning curve, as the first time you’re presented with one it isn’t necessarily clear what it does unless you’ve encountered them before. Like I say it can be ambiguous at the call-site in particular, as it doesn’t show that an array of [Foo] is being passed as opposed to N instances of Foo (however many are in the call).</div><div class=""><br class=""></div><div class="">While I’ve used them in the past, I’ve never really felt that they simplify anything enough to justify them, as it’s just two square brackets extra to pass an array; this is extra noise sure, but clarifies what is actually happening.</div><div class=""><br class=""></div><div class="">So if variadic functions don’t have any other advantages, then it’s really just a very minor piece of syntactic sugar that can lead to more confusion, less explicit types in function calls, an extra piece of syntax to parse and handle and possibly other features required to support it better (like the one being inquired about). The only other argument I can think of for them is that many other languages have them, but that’s not important to me vs cutting out cruft.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Short version; removing variadic functions would solve the problem of defining overloads for both variadic and array types by only ever requiring the latter.</div><div class=""><br class=""></div><div class="">P.S- I’d also like to note that where possible people should be accepting Sequences or Collections in their methods anyway rather than arrays specifically, as it’s more flexible that way ;)</div></div></blockquote></div></div></blockquote></div><br class=""></body></html>