I like this proposal. I was a bit against when the discussion around the removal of variadics arose, but I fee that this proposal takes a good whack at the problem.
I have struggled with array vs. variadic arguments for several methods, ending up implementing both overloads and the variadic method only passed the arguments to the overload that took an array as an argument. This would nicely eliminate the need for such "hacks". > On Jul 8, 2016, at 12:03 AM, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 7 Jul 2016, at 22:39, Leonardo Pessoa <[email protected]> wrote: >> >> I think we'd have less effort (and less breaking more >> backward compatibility) if we just allow variadic arguments to receive >> arrays of its type directly. > > This proposal doesn't just handle the issue of passing an array however, it > also allows variadics of any type of your choice (so long as it conforms to > ArrayLiteralConvertible) rather than it always being an Array. Likewise it > would also support any generic iterator, sequence or collection; while > calling the function in variadic style would just result in some default type > behind the scenes, you can also pass in anything you like using a variable > (just like you can to a regular method). > > Also one other advantage I didn't list is that an attribute could support > future extensions, for example the ability to set something like > @variadic(minimum: 1), causing the compiler to produce an error if a variadic > call is empty. Beyond the scope of this initial proposal, but basically this > seems a much more flexible way to do things than trying to layer support onto > the existing syntax, though it could be retained as a shorthand. > _______________________________________________ > 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
