[swift-evolution] Proposal for Passing Arrays to Variadic Functions

[Kevin Ballard]

Yeah, except you'd never actually write myFunc([T]...), because you can
just say myFunc(T) in that case. So it would really be used like
myFunc(args...)

@autoclosure isn't a keyword, it's an attribute. AFAIK we have no
precedence for attributes on expressions, only on declarations. And I'd
think we'd need to have a really compelling reason to start putting
attributes on expressions, since that's kind of weird.

-Kevin

On Fri, Dec 11, 2015, at 11:20 PM, Arthur Ariel Sabintsev wrote:
> Just to make sure we're on the same page, your suggestion is the
> following:
>
> // Declaration func myFunc(v: T...) {}
>
> // Call myFunc([T]...)
>
> That seems quite ugly, no? I'd prefer the use of a keyword at that
> point, kind of like we have @autoclosure, but instead of declaring the
> keyword in the function definition, we use the keyword (e.g.,
> @variadic) in the function call.
>
> Thoughts on that?
>
> Best,
>
> Arthur / Sabintsev.com[1]
>
> On Sat, Dec 12, 2015 at 2:15 AM, Kevin Ballard <kevin at sb.org> wrote:
>> __
>> Using any operator at all is a problem. The only way that can work
>> without conflict is if the operator returns some special type that is
>> known to the compiler to represent a variadic call, but that doesn't
>> seem like a great idea. What do you think of the ... suffix? That
>> can't conflict with operators, and it matches the variadic function
>> declaration.
>>
>>
>> -Kevin
>>
>>
>> On Fri, Dec 11, 2015, at 11:12 PM, Arthur Ariel Sabintsev wrote:
>>> Thanks for your response.
>>>
>>> The reason this doesn't work is due to Swift's generic system as it
>>> allows a type T to be a anything, including arrays. The example that
>>> was used to delineate this concept to me was that of "Any...", which
>>> from within the variadic function, could be interpreted as T or [T].
>>> The result is ambiguous in the current implementation, which is why
>>> some identifier syntax needs be passed along with an array to get
>>> this to work properly.
>>>
>>> As for the choice of operator, I'm open to suggestions. I wanted to
>>> use one that was familiar to other developers, so I chose the one
>>> that Ruby uses.
>>>
>>> Maybe a ~ would be better, or a keyword like @variadic?
>>>
>>>
>>> Best,
>>>
>>> Arthur / Sabintsev.com[2]
>>>
>>> On Sat, Dec 12, 2015 at 1:54 AM, Kevin Ballard via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>> __
>>>> You can't use * as suggested, because that conflicts with * as a
>>>> prefix operator.
>>>>
>>>> You could probably get away with using a trailing ... in the call,
>>>> as in
>>>>
>>>> func foo(xs: [Int]...) {    bar(xs...) }
>>>>
>>>> I also wonder whether there's a reason Swift doesn't already
>>>> support this. Maybe there's some desired future change to variadic
>>>> arguments to improve performance (i.e. to avoid having to allocate
>>>> an array) that wouldn't be compatible? Although I'm not sure what
>>>> that would be. Maybe there's actually no barrier at all and it was
>>>> just something that wasn't prioritized. It would be good to know
>>>> either way.
>>>>
>>>> -Kevin
>>>>
>>>> On Fri, Dec 11, 2015, at 10:43 PM, Arthur Sabintsev via swift-
>>>> evolution wrote:
>>>>> Hi,
>>>>>
>>>>> I have put together a proposal for passing arrays to variadic
>>>>> functions (along the lines of Ruby’s Splay operator).
>>>>>
>>>>> Proposal:
>>>>> https://github.com/ArtSabintsev/swift-evolution/blob/master/proposals/array-variadic-function.md
>>>>> Pull Request: https://github.com/apple/swift-evolution/pull/52 Bug
>>>>> Report: https://bugs.swift.org/browse/SR-128 which led to this
>>>>> proposal
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Arthur / Sabintsev.com[3]
>>>>>
>>>>> _________________________________________________
>>>>> swift-evolution mailing list swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>



Links:

  1. http://sabintsev.com/
  2. http://sabintsev.com/
  3. http://sabintsev.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/ac96134c/attachment.html>