[swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa]

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 <kristof.liliom at mattakis.com> 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
> <swift-evolution at swift.org> wrote:
>
>
> On 8 Jul 2016, at 12:03, Leonardo Pessoa <me at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>