The proposal is indeed really interesting. I would love to see if it could get a second round of discussion.
However, I failed to understand the syntax of the proposed extension. Where would be defined the label and parameter names? Is this just a typo? func someFunc<I:IteratorProtocol where I.Element == Int) Thanks, Dimitri On 11 Feb 2017, at 13:08, Tino Heth <2...@gmx.de<mailto:2...@gmx.de>> wrote: 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 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
