> On 26 Feb 2017, at 19:17, Derrick Ho via swift-evolution > <[email protected]> wrote: > > That is an interesting solution. Haravikk's solution was a breaking change > so it undoubtedly had resistance.
IMHO, it's a more elegant solution to the same problem. I might be worth pursuing it despite the breaking change because it has more chance of being considered than pure syntactic sugar which the core team is not even considering before Swift 4. > If we were to merely allow Arrays to be cast as type String... then there > were be nothing to break. > > String... is technically not a real type though, so when you use it anywhere > outside of a functions argument list, it will not compile. > > Maybe we can make a special case? > >> On Sun, Feb 26, 2017 at 12:25 PM Tino Heth <[email protected]> wrote: >> I suggest to take a look at the topics "Variadics as an Attribute" and >> "array splatting for variadic parameters" and >> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md. >> >> This is basically the other way round (arrays would accept variadic >> arguments), but it has the same effect — and more: >> You get rid of the odd "…" type, and it's also possible to use this with >> types besides array (set, iterator….) > _______________________________________________ > 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
