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

[Vladimir.S]

+1 to remove them(vararg) or introduce special marker for variadic params.

IMO: I think variadic parameters is alien construction in Swift, where we 
expect that the method call explicitly tells us what is the purpose of each 
parameter by using external param names.

Plus, variadic parameters are actually array of values. We don't like if 
something is implicit in Swift. If we pass an array of values, why we 
allows this without specifying array's [] explicity.
Or, why there is no explicit marker for such method that it has variadic 
parameters(don't know, something like .select(:id, name)). Probably this 
will be an OK solution also - to have special marker for variadic parameters.

Yes, I expect to see .select(id, withName: name). Construction like 
.select(id, name) seems like incorrectly defined method(w/o external name 
for second parameter).

Btw, for those who like variadic parameters: Do you support that Swift 3.0 
will not allow a tuple instead of prarameters for methods?
https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md
This feature also was used and probably can be handful in some situations. 
But, one of the main reasons why it was(will be) removed (Quote):
* A call to foo(x) looks like a call to an overloaded version of foo, both 
to the compiler and to the human who maintains the code. This is extremely 
confusing if you don't know the feature exists.
*(?) The current implementation adds complexity to the type checker, 
slowing it down and adding maintenance burden.


On 18.04.2016 15:55, Dennis Weissmann via swift-evolution wrote:
 > Hm, sorry but I’m still not convinced :(
 >
 > I still find it confusing and I think if it wasn’t in Swift already, it
 > would not be added. Maybe someone can come up with a strong reason why it
 > should be added if it weren’t there.
 >
 > - Dennis
 >
 >> On Apr 18, 2016, at 10:10 AM, Gwendal Roué <gwendal.roue at gmail.com
 >> <mailto:gwendal.roue at gmail.com>> wrote:
 >>
 >>
 >>> Le 18 avr. 2016 à 10:02, Dennis Weissmann <dennis at dennisweissmann.me
 >>> <mailto:dennis at dennisweissmann.me>> a écrit :
 >>>
 >>> 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.
 >>
 >> Sorry my example wasn’t clear enough, and that’s why you couldn’t tell by
 >> looking at the call site what was happening. You were missing context.
 >> "id" and "name" are not values, they’re database columns. It’s more
 >> something along:
 >>
 >> DatabaseTable {
 >> func select(columns: Column…) { … }
 >> }
 >>
 >> people.select(idColumn, nameColumn)
 >> furniture.select(nameColumn, widthColumn, heightColumn, depthColumn,
 >> priceColumn)
 >>
 >> (Sometimes examples are too complex, and don't serve well their purpose -
 >> my mistake)
 >>
 >> Maybe you’ll follow the counter argument now. Which is "of course a
 >> variadic function can always be turned into a function that takes an
 >> array, what a surprise, but this is not always the good thing to do."
 >>
 >> Regards,
 >> Gwendal Roué
 >
 >
 >
 > _______________________________________________
 > swift-evolution mailing list
 > swift-evolution at swift.org
 > https://lists.swift.org/mailman/listinfo/swift-evolution
 >