[swift-evolution] [Idea] Passing an Array to Variadic Functions

[Vladimir.S]

On 20.04.2016 23:27, Slava Pestov wrote:
>
>> On Apr 19, 2016, at 10:54 AM, Haravikk via swift-evolution
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>   * Possibly optimisations unavailable to Array passing?
>
> Indeed, it should be possible to implement varargs by allocating the
> argument array on the stack (and having the compiler implicitly copy it to
> the heap inside the callee if it escapes). Although you can imagine this
> type of optimization being performed for arbitrary arrays, it would be more
> difficult and less predictable.

But what about situations when we need to pass an array to function that 
accepts only variadic params? Don't we need some #splat() function?

>
> Slava
>
>>
>> *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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>