That’s a possibility (at least for our use case). 

In our closed-source project we have 17 functions that take variadic 
parameters. In all cases it’s done that way because it’s possible for the 
caller to pass a comma separated list of values but the most common case is to 
only pass a single argument. Additionally, we might want to enforce that at 
least one value is passed (using a single value parameter and an unlabeled 
variadic parameter after that). 
(the example below is Swift 2.2 syntax)

// requires zero or more arguments
func foo(xs: Int ...) {}

// requires one or more arguments
func bar(x: Int, _ xs: Int ...) {}

The second case would looks really strange without the variadic parameter 
(calling site) syntax and it would no longer look like it’s one continuous list 
of values.

As long as we can keep the call site syntactical benefits of variadic 
parameters and do thing like the above, I’m fine with changing the way it’s 
defined / works internally. 
  
- David

> On 07 Jul 2016, at 10:07, Haravikk <swift-evolut...@haravikk.me> wrote:
> 
> 
>> On 6 Jul 2016, at 21:13, David Rönnqvist via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I'd be reluctant to remove variadic parameters. We've found on our team that 
>> variadic arguments are easier to read on the call site compared to array 
>> arguments, especially when it's common to pass a single value (but still 
>> possible to pass multiple values).
>> 
>> - David
> 
> I'm very much in the remove-them camp, however I do wonder if there might be 
> another way to handle them? In other words, when defining a method we should 
> always define an array, but perhaps we could use an attribute to selectively 
> turn any Sequence or Iterator parameter into a variadic, like-so:
> 
>       func someMethod(@variadic _ values:[Int]) { … }
> 
> This can be called using the developers preference between:
> 
>       someMethod([1, 2, 3, 4, 5, 6])
>       someMethod(1, 2, 3, 4, 5, 6)
> 
> So long as there's no ambiguity of course. This should have a few advantages 
> over the current variadics:
> 
> No unique declaration syntax
> Reinforces that a variadic function is just a function taking some kind of 
> Collection
> Enables us to choose the type of the parameter from any Iterator, Sequence or 
> Collection.
> Allows developers to choose the function's form at the call-site between 
> passing a collection/sequence/iterator or a list of values. Also an array 
> literal if the chosen type supports that as in the example above.
> Allows passing of an array literal or appropriate Collection type.
> An attribute is more discoverable (option-click in Xcode to view 
> documentation).
> 
> Any got any thoughts on this alternative?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to