> func f(_ args: [Int]) {
> // Some implementation ...
> }
>
> func f(_ args: Int…) {
> f(args)
> }
>
> Some people also advocate (myself generally included) that one should prefer
> the signature explicitly marking args as an array, as the syntactic overhead
> of wrapping the arguments with “[]” when calling f is arguably bearable.
> However, in some other situations, this approach might not be applicable. For
> instance, one may simply not be able to modify the original function. Another
> use-case may be a function that should forward its own variadic parameters.
There has been a proposal that would not only solve this issue, but also add a
lot flexibility while simplifying the language at the same time:
https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md
<https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md>
Imho it's one of the best ideas I have seen on evolution, and definitely the
most valuable segregation of C legacy.
Sadly, it was discussed in a very busy timeframe, and I think it really didn't
receive the attention it deserves…
I would have asked Haravikk wether he would like to start a second try anyways,
and as this topic is directly related, it's a good motivation to do so.
The basic idea of the proposal is to get rid of "…"-magic and declare variadic
parameters with their natural type (Array<T> — but one aspect of this idea is
that it can be extended easily to work with sets and other types that can be
expressed with an array literal).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
