<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=""><div class="">That’s a possibility (at least for our use case). </div><div class=""><br class=""></div><div class="">In our closed-source project we have 17 functions that take variadic parameters. In all cases it’s done that way because it’s possible for the caller to pass a comma separated list of values but the most common case is to only pass a single argument. Additionally, we might want to enforce that <b class="">at least</b> one value is passed (using a single value parameter and an unlabeled variadic parameter after that). </div><div class="">(the example below is Swift 2.2 syntax)</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">// requires zero or more arguments</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> foo(xs: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class=""> ...) </span>{}</div><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><br class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span></div><div style="margin: 0px; line-height: normal; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">// requires one or more arguments</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> bar(x: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">_</span><span style="font-variant-ligatures: no-common-ligatures" class=""> xs: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class=""> ...) </span><span style="font-variant-ligatures: no-common-ligatures;" class="">{</span>}</div></div></div><div class=""><br class=""></div><div class="">The second case would looks really strange without the variadic parameter (calling site) syntax and it would no longer look like it’s one continuous list of values.</div><div class=""><br class=""></div><div class="">As long as we can keep the call site syntactical benefits of variadic parameters and do thing like the above, I’m fine with changing the way it’s defined / works internally. </div><div class=""> </div><div class="">- David</div><br class=""><div><blockquote type="cite" class=""><div class="">On 07 Jul 2016, at 10:07, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 6 Jul 2016, at 21:13, David Rönnqvist via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'd be reluctant to remove variadic parameters. We've found on our team that variadic arguments are easier to read on the call site compared to array arguments, especially when it's common to pass a single value (but still possible to pass multiple values).<br class=""><br class="">- David</div></div></blockquote><br class=""></div><div class="">I'm very much in the remove-them camp, however I do wonder if there might be another way to handle them? In other words, when defining a method we should always define an array, but perhaps we could use an attribute to selectively turn any Sequence or Iterator parameter into a variadic, like-so:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>func someMethod(@variadic _ values:[Int]) { … }</font></div><div class=""><br class=""></div><div class="">This can be called using the developers preference between:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>someMethod([1, 2, 3, 4, 5, 6])</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre">        </span>someMethod(1, 2, 3, 4, 5, 6)</font></div><div class=""><br class=""></div><div class="">So long as there's no ambiguity of course. This should have a few advantages over the current variadics:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">No unique declaration syntax</li><li class="">Reinforces that a variadic function is just a function taking some kind of Collection</li><li class="">Enables us to choose the type of the parameter from any Iterator, Sequence or Collection.</li><li class="">Allows developers to choose the function's form at the call-site between passing a collection/sequence/iterator or a list of values. Also an array literal if the chosen type supports that as in the example above.</li><li class="">Allows passing of an array literal or appropriate Collection type.</li><li class="">An attribute is more discoverable (option-click in Xcode to view documentation).</li></ul><div class=""><br class=""></div><div class="">Any got any thoughts on this alternative?</div></div></div></div></blockquote></div><br class=""></body></html>