> On 19 Apr 2016, at 20:25, Justin Jia <[email protected]> wrote:
>
> Cons of removing variadic functions:
> 1. More verbose syntax.
> 2. Break old code.
The verbosity is only two characters (square brackets), and it needn’t break
old code:
Before: func myFunc(values:Foo…)
After: func myFunc(values:[Foo])
Before: myFunc(foo, bar, baz)
After: myFunc([foo, bar, baz])
Currently variadic functions just produce an array of arguments anyway, so
simply translating call-sites to pass in an array guarantees compatibility.
> On Apr 19, 2016, at 10:54 AM, Haravikk <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> On 19 Apr 2016, at 17:51, Vladimir.S <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> I.e. the question is *if we want/need to be able to pass array to existed
>>> variadic function*. Not about removing the variadic feature("removing" is
>>> offtop for this poposal, as I understand)
>>
>> I’d say it’s on-topic, as removing variadic functions would eliminate the
>> problem entirely, so if it is considered a better alternative then there
>> would be no need to have an additional means of calling them with an array
>> of arguments.
>>
>> Personally the way I see it comes down to variadic functions is this:
>>
>> Pros:
>> Slightly cleaner syntax at call-site.
>> Possibly optimisations unavailable to Array passing?
>>
>> Cons:
>> Doesn’t do anything that passing an array directly can’t.
>> Passing an array is actually slightly more flexible (can dynamically pass
>> more or less arguments as required at the call site).
>> Less explicit type at call site; gives the appearance of passing instance(s)
>> of Foo, rather than one instance of [Foo], can lead to ambiguity with
>> overloaded functions.
>> Extra syntax to support (enabling array passing would be more code required
>> to support this feature)
>>
>> I’d also argue that variadic functions increase the learning curve, as the
>> first time you’re presented with one it isn’t necessarily clear what it does
>> unless you’ve encountered them before. Like I say it can be ambiguous at the
>> call-site in particular, as it doesn’t show that an array of [Foo] is being
>> passed as opposed to N instances of Foo (however many are in the call).
>>
>> While I’ve used them in the past, I’ve never really felt that they simplify
>> anything enough to justify them, as it’s just two square brackets extra to
>> pass an array; this is extra noise sure, but clarifies what is actually
>> happening.
>>
>> So if variadic functions don’t have any other advantages, then it’s really
>> just a very minor piece of syntactic sugar that can lead to more confusion,
>> less explicit types in function calls, an extra piece of syntax to parse and
>> handle and possibly other features required to support it better (like the
>> one being inquired about). The only other argument I can think of for them
>> is that many other languages have them, but that’s not important to me vs
>> cutting out cruft.
>>
>>
>> Short version; removing variadic functions would solve the problem of
>> defining overloads for both variadic and array types by only ever requiring
>> the latter.
>>
>> P.S- I’d also like to note that where possible people should be accepting
>> Sequences or Collections in their methods anyway rather than arrays
>> specifically, as it’s more flexible that way ;)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
