> On 8 Jul 2016, at 21:18, Kristóf Liliom <[email protected]> wrote:
>
> 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?
These are a possible compromise certainly, but it's not exactly pretty, as I'm
not sure it would eliminate the desire to define collection-based methods
anyway, as it'll still be neater to just define both so you can do
someMethod(values) directly (when it's not ambiguous), in which case this
capability only really benefits us when only the variadic option is defined and
we have no choice but to use it which feels a little like solving the wrong
problem (we'd be working around a developer's unwillingness to define flexible
options).
Part of my aim with this proposal is to remove variadic function declarations
as being this weird kind of special function type, so we can just use a
standard function declaration and enable the part that actually makes them
different; the way they're called.
While the issue of ambiguity is a real one, it seems to me that the problem is
specific to Any…, or any other type that can represent both a collection and
the elements it can contain. Another possible solution could just be a
parameter on this proposal's attribute so we can solve the issue as we do now,
for example:
func print(@variadic(only) _ values:[Any]) { print(contentsOf: values)
} // Can only be called variadically
func print(contentsOf:[Any]) { … } // Can only be called with an array
Here we resolve the ambiguity exactly as we do right now; with one
variadic-only declaration, and one array-only declaration. However, for cases
where the type isn't Any (and thus should be unambiguous) we will only need a
single function to handle both cases.
I know that Any… is necessary for print-style methods like the above example,
but other than that how common is it?_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
