[swift-evolution] [Proposal] Variadics as Attribute

Haravikk swift-evolution at haravikk.me
Fri Jul 8 04:57:44 CDT 2016

```> On 8 Jul 2016, at 10:31, Pyry Jahkola <pyry.jahkola at iki.fi> wrote:
>
> 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)...)

Good point, but actually these don't seem mutually exclusive; the three problem examples you gave could be resolved either by requiring the extra set of square brackets for clarity, and/or some kind of expansion like you suggest, either an operator or even possibly repurposing the attribute at the call-site for consistency. For example:

printThem([1])	// warning, ambiguous
printThem([[1]])// non-variadic
printThem(@variadic [1]) // absolutely definitely 100% a variadic call
printThem([1],) // alternative to an operator/attribute for variadic disambiguation?

Thoughts?

> On 8 Jul 2016, at 10:42, Tino Heth <2th at gmx.de> wrote:
> I'm not sure if the timing of this proposal is coincidence (I recently revived a discussion to remove variadics)

It is definitely not a coincidence ;)
I participated in the discussion on removal in the past and actually posted a preliminary version of this there, so the recent posts reminded me to put it into a proper proposal. Personally like some I'd just remove the feature completely, but it seems enough people want to keep it that it's worth exploring alternatives as there seems a fairly even mix of those for and against the feature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/76f7cc8d/attachment.html>
```

More information about the swift-evolution mailing list