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é <[email protected]> wrote: > > >> Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution >> <[email protected]> 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é >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
