I think if Int... === [Int] would be true, then it would introduce a new set of ambiguity and defaulting to a specific behaviour would be a "good guess" rather than a reliable logic.
Best, Kristóf > On 08 Jul 2016, at 22:24, Leonardo Pessoa <[email protected]> wrote: > > Kristof, this is the closest to what I've been proposing but I'm > really unable to understand why it is to had to just change the > compiler to recognise an array passed as argument to a variadic > argument. No need for any extra keywords or complicated solutions, > just make the compiler recognise that "Int... === [Int]" and we have > the issue solved: it accepts both and array of ints or multiple ints > in its arguments. > > L > > On 8 July 2016 at 17:18, Kristóf Liliom <[email protected]> wrote: >> 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 >> <[email protected]> wrote: >> >> >> On 8 Jul 2016, at 12:03, Leonardo Pessoa <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
