Hi!
I read through this proposal, and I have the feeling that we are trying to
solve an issue with Swift from the wrong angle. IMHO Swift has one of the best
implementations of variadics which has only one major downfall: passing an
array as a variadic argument is not possible. Maybe it would be a better idea
to leave method declarations as is and only change the call-site as something
like this:
func someMethod(_ values:Int...) { /* values: 1, 2, 3, 4 */ }
func someMethod2(_ values:Int...) {
someMethod(#unpack(values)) // Or #variadic
}
someMethod2(1, 2, 3, 4)
This would tell the compiler to pass the array's values. Maybe in a more
advanced scenario, even this could be supported:
func someMethod(_ values:Int...) { /* values: -1, -2, 1, 2, 3, 4, -3, -4 */ }
func someMethod2(_ values:Int...) {
someMethod(-1, -2, #unpack(values), -3, -4) // Or #variadic
}
someMethod2(1, 2, 3, 4)
I know this is not a well defined idea, but please give it a thought, could it
be a feasible solution to this problem?
Best,
Kristóf
> On 08 Jul 2016, at 13:43, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 8 Jul 2016, at 12:03, Leonardo Pessoa <m...@lmpessoa.com
>> <mailto:m...@lmpessoa.com>> wrote:
>> You would have to add some extra code on the compiler to check whether you
>> can use that type for your variadics argument and may incur in more changes
>> to enable handling different classes possible.
>
> Not really; the variadic call just needs to be treated as if it is an array
> literal, at which point the compiler will either match a method or it won't.
> The only real difference is that when called as a variadic the compiler will
> only match functions with the @variadic attribute. In other words the
> following resolve in much the same way:
>
> someMethod([1, 2, 3, 4, 5, 6]) // Looks for a declaration of
> someMethod() that can take an array literal
> someMethod(1, 2, 3, 4, 5, 6) // Looks for a declaration of
> someMethod() that can take an array literal, and has a @variadic parameter
>
> Treating the trailing ellipsis as a shorthand for [Foo] is no different in
> that respect, it's just limited to Array only. In other words, if an array
> literal cannot be accepted by the parameter, then it cannot have the
> @variadic attribute, we'd need a compiler expert to comment but I don't think
> that should be that hard to check (concrete types will be checked for
> conformance to ArrayLiteralConvertible, and generics will be checked to see
> if they can be fulfilled by an Array or some kind of ArrayLiteral type).
>
> Really what it comes down to is a choice between two methods of solving the
> array passing problem:
>
> Variadic function treated as regular function with array parameter.
> Regular function gains ability to be called (optionally) in variadic style at
> call site.
>
> But my preference is for the latter as it eliminates the variadic function
> declarations as being some kind of special case, and moves it into a feature
> of regular function declarations.
>
>> I would also expect to be able to use dictionaries as variadics with this
>> syntax, and that would be confusing too.
>
> This should only be the case I think if you've extended Dictionary with an
> ArrayLiteralConvertible initialiser, or you declared your function to take a
> generic iterator/sequence/collection with elements of type (Key, Value) in
> which case, yes, a Dictionary could fulfil the requirements.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
