> Le 18 avr. 2016 à 10:02, Dennis Weissmann <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
