I meant only for the sake of variadics. That would "teach" the compiler to read "func x(args : Int...)" from our code and interpret it too as "func x(args ; [Int])" thus accepting lists of arguments or an array with the arguments with no additional effort from our part.
L On 8 July 2016 at 17:29, Kristóf Liliom <[email protected]> wrote: > 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
