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

[Arthur Sabintsev]

You’re right, it’s an attribute. My mistake.

I’d actually prefer to only have to use an operator when the compiler throws a warning stating that the input is ambiguous, as is the case with Any, [Any], AnyObject, and [AnyObject].

Best,

Arthur / Sabintsev.com

On December 12, 2015 at 5:44:16 AM, Marc Knaup (marc at knaup.koeln) wrote:

Why not omit the operator:

myFunc([T])

and only require it to disambiguate cases like "Any...":

myFunc([T]...)

Ambiguous cases should be rather uncommon anyway.

On Sat, Dec 12, 2015 at 9:03 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
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
 
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
 
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

_______________________________________________
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
 
 
 


_______________________________________________
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/20151212/9bf5d449/attachment.html>