<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="">That’s IMO already a problematic case:<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>DatabaseTable.select(id, name).order(name, id)<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>// What’s the problem?<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// vs.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>DatabaseTable.select([id, name]).order([name, id])<span class="Apple-tab-span" style="white-space: pre;"> </span>// OK, of course... But some people will find it a litle short<br class=""></blockquote></div><div class=""><br class=""></div><div class="">The problem is that you can’t tell by looking at the call site whether `select` takes an id and a name as parameter (the function being declared as `func select(id: String, _ name: String)` or a vararg `func select(string: String…)`.</div><div class="">Both call sites look like this:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">select(id, name)</blockquote></div><div class=""><br class=""></div><div class="">I think it would make the language clearer and more consistent if varargs were removed.</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Dennis</div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Apr 18, 2016, at 9:48 AM, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class=""><blockquote type="cite" class="">Why not remove varargs altogether from Swift, it is easy enough to put [] round a list?<br class=""></blockquote><br class="">+1, that was my thought too. I can’t think of a use case where you can’t use an array instead of varargs (this assumes all vararg parameters are converted to array parameters).<br class=""></blockquote><br class="">Oh no please no. Of course a variadic function can always be rewritten as a function that takes an array. Of course. You always can use an array. Got it. But some APIs are nicer with varargs. And even nicer APIs go over the top by adding support for arrays too, because not all lists are known at compile time. It’s a matter of being sensible.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>DatabaseTable.select(id, name).order(name, id)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// What’s the problem?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// vs.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>DatabaseTable.select([id, name]).order([name, id])<span class="Apple-tab-span" style="white-space:pre"> </span>// OK, of course... But some people will find it a litle short<br class=""><br class="">Gwendal Roué<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>