[swift-evolution] [Proposal] Variadics as Attribute

[Pyry Jahkola]

I agree that we should have a way to call a variadic function with an Array at hand, without needing to take its elements apart (`foo(x[0], x[1], x[2])`) — which indeed is only practical when we statically know its length.

But I fear there's a shortcoming in this proposal that hasn't been addressed: How would the compiler clear the ambiguity in single-argument calls between existentials such as `Any` or `CustomStringConvertible` and sequences thereof (e.g. `[Any]` or `[CustomStringConvertible]`, which both can be treated as `Any` and `CustomStringConvertible` as well?

If you take this function for example,

    func printThem(@variadic _ values: [Any])

then what would `values` be in the following calls, and why?

    printThem() // clearly []
    printThem(1) // clearly [1]
    printThem(1, 2) // clearly [1, 2]
    printThem([1], [2]) // clearly [[1], [2]]
    printThem([]) // [] or [[]], which one?
    printThem([1]) // [1] or [[1]]?
    printThem([1, 2]) // [1, 2] or [[1, 2]]?

I think it would be less painful a change (i.e. can be delayed past Swift 3) if we just augment what we have (the `...` argument declaration syntax) with a way to expand an Array in place of a variadic argument:

    func printThem(_ values: Any...)

    printThem(1) // values == [1]
    printThem([1]) // values == [[1]]
    // Possible expansion postfix syntax:
    printThem([1]...) // values == [1]
    // Expanding a non-array sequence:
    let things: Set<Int> = [1, 2, 3]
    printThem(Array(things)...)

I think variadic functions are intended for human convenience and rarely used in performance-critical code, and it's probably more convenient that they're always passed as an Array, and not as a generic sequence.

— Pyry

Haravikk wrote:

> For example, consider the following variadic function:
> 
> func someMethod(_ values:Int...) { … }
> Under this proposal the above can be rewritten as one of the following:
> 
> func someMethod(@variadic _ values:[Int]) { … } // Basic Array solution
> func someMethod(@variadic _ values:Foo) { … }   // Foo is a custom ArrayLiteralConvertible type
> func someMethod<I:IteratorProtocol where I.Element == Int>(@variadic _ values:I) { … } // Flexible, single-pass, generic solution
> func someMethod<S:Sequence where S.Iterator.Element == Int>(@variadic _ values:S) { … } // Flexible, (probably) multi-pass, generic solution
> func someMethod<C:Collection where C.Iterator.Element == Int>(@variadic _ values:C) { … } // Flexible, definitely multi-pass, indexed, generic solution
> In this case the Iterator variation is preferred for greatest flexibility, but it will depend upon the actual requirements of the method. Any of these can be called as follows:
> 
> someMethod([1, 2, 3, 4, 5, 6])  // normal array-literal call for any of the above
> someMethod(1, 2, 3, 4, 5, 6)    // variadic call, synonymous with array-literal call
> someMethod(foo)                 // foo is an existing Array, Foo, Iterator, Sequence or Collection variable as appropriate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/9cf83076/attachment.html>