[swift-evolution] [Proposal] Allow passing a variadic parameter to another variadic function

Christopher Boyd xpboyd at gmail.com
Fri May 20 13:12:15 CDT 2016


Jaden,

That's a good point.

In C#, variadic parameters explicitly stated to be arrays.

This means that in C#, this never occurs because:
foo(params int[] bar)
has the same signature as
foo(int[] bar)

Thus, you can't have both commands defined as they're identified to be
conflicting overloads.  In fact, it's what allows you to simply pass an int
array to foo(params int[] bar).

The params keyword basically just specifies to be an accumulator for
multiple parameters.

Meanwhile, in Swift you can have a single class with all of the following:
foo(bar: Int)
foo(bar: Int...)
foo(bar: [Int])

For the syntax to work without a #splat operator, methods with Int... and
[Int] would have to be considered as equivalent signatures.

On Fri, May 20, 2016 at 12:56 PM <jaden.geller at gmail.com> wrote:

> Sure, but imagine it weren't generics. Instead, we have two specialized
> functions, the first identical the generic one with T = Int and the second
> with T = [Int]. We have the same problem again.
>
> Jaden
>
> On May 20, 2016, at 9:50 AM, Christopher Boyd <xpboyd at gmail.com> wrote:
>
> Jaden,
>
> In that very specific example with generics, couldn't you just explicitly
> specify foo<[T]>(bar: bar)?
>
> On Fri, May 20, 2016 at 12:39 PM <jaden.geller at gmail.com> wrote:
>
>> Without it, there could be ambiguity. Observe:
>>
>> func foo<T>(bar: [T]...) {
>>   foo(bar: bar) // splat or pass single arg?
>> }
>>
>> - Jaden Geller
>> Sent from my iPhone
>>
>> On May 20, 2016, at 9:29 AM, Christopher Boyd via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Vladimir,
>>
>> True, but does the extra syntax actually accomplish anything?
>>
>> From my example:
>>
>>    - func arithmeticMean(numbers: Double...) -> Double {
>>    - return add(numbers) / Double(numbers.count)
>>    - }
>>
>>
>> It's clear that the intent is to pass all the numbers to add().
>>
>> What, exactly, does adding the #splat() syntax achieve?  It doesn't add
>> any additional clarity.
>>
>> Moreover, I don't think #splat has been accepted as a proposal yet.
>>
>> On Fri, May 20, 2016 at 12:19 PM Vladimir.S <svabox at gmail.com> wrote:
>>
>>> [offtopic]
>>> On 20.05.2016 19:08, Christopher Boyd via swift-evolution wrote:
>>> > Certainly, #splat would work, but it may be slightly more confusing to
>>> > someone that hasn't seen the splat operator before:
>>> So, he/she will open swift documentation or drop the question to google
>>> once, and from that moment will know what #splat means.
>>> [/offtopic]
>>>
>> _______________________________________________
>>
>>
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/6a45d7db/attachment.html>


More information about the swift-evolution mailing list