[swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann]

That’s IMO already a problematic case:

> 	DatabaseTable.select(id, name).order(name, id)		// What’s the problem?
> 	// vs.
> 	DatabaseTable.select([id, name]).order([name, id])	// OK, of course... But some people will find it a litle short


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…)`.
Both call sites look like this:

> select(id, name)


I think it would make the language clearer and more consistent if varargs were removed.

- Dennis

> On Apr 18, 2016, at 9:48 AM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
> 
> 
>> Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>> Why not remove varargs altogether from Swift, it is easy enough to put [] round a list?
>> 
>> +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).
> 
> 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.
> 
> 	DatabaseTable.select(id, name).order(name, id)		// What’s the problem?
> 	// vs.
> 	DatabaseTable.select([id, name]).order([name, id])	// OK, of course... But some people will find it a litle short
> 
> Gwendal Roué
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160418/abcab174/attachment.html>