<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 20 Jul 2016, at 20:54, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 20 Jul 2016, at 14:55, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">Am 17.07.2016 um 18:31 schrieb Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>>:<br class=""><br class="">I may move discussion of other collection types to its own section though, to make the core proposal as simple as possible, and leave it up to the core team whether to do that part.<br class=""></blockquote>imho this is a good idea: Its increased power is a major argument for the proposal, but the schedule seems to be very tight already… and I guess the discussion about possible problems caused by variadic functions which can be called with an explicit collection could be a real distraction, whereas the basic idea is so clear that there shouldn't be any valid reasons to not accept it.<br class=""></blockquote><br class="">I've created a new pull request for this, you can view the updated file here:<br class=""><a href="https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md" class="">https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md</a><br class=""><br class="">Hopefully it's still clear; I know I have a nasty tendency to be overly verbose with wording and stuff, though the first example should keep the meat of the proposal straightforward =)<br class=""></blockquote><br class="">I’m sorry I’m late to this thread, but I’m personally strongly opposed to this.</div></div></blockquote><br class=""></div><div>I'm similarly late to your reply since somehow I missed it ;)</div><div><br class=""></div><div><blockquote type="cite" class="">The problem being solved here is so minor that I don’t see a reason to make a change. </blockquote><div><br class=""></div><div>Which problem are you referring to exactly? The core issue of the proposal is to eliminate an unnecessary custom syntax and use regular function declarations, but the proposal also extends further than that as detailed in the advantages section; firstly it also opens passing of arrays to variadic functions, which seems to be fairly desired despite no proposal that I could find, but this proposal does so using a regular function definition rather than bolting on more custom behaviour to variadics. The proposal also details how the use of an attribute allows selection of any suitable type for handling the variadics, either to be introduced now or as a future feature, allowing any ArrayLiteralConvertible or any generic that can be satisfied by an Array to be used in an implementation, rather than requiring:</div><div><br class=""></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someFunc<I:IteratorProtocol where I.Element == Int>(contentsOf:I) { … }</font></div><div><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someFucn(_ values:Int…) { someFunc(contentsOf: values) }</font></div><div><br class=""></div><div>You would just pop the @variadic attribute on the first version.</div><div><br class=""></div><div>Again on the future feature front, if we were to get any new variadic features the use of an attribute should make them easier to add since they could be added as an attribute parameter. Not that I can think of any, but in future it would be easy to add say @variadic(min: 1) to set a minimum number of variadic parameters; not that I want this, it's just the only thing I can think of, but highlights that an attribute is more extensible.</div><div><br class=""></div><div>So while the problem inspiring the proposal is relatively minor, the solution aims to solve the array passing issue too, while opening up other possibilities now or in future.</div><br class=""><blockquote type="cite" class="">Further, the proposed syntax is so heavy weight that it will adversely affect readability of the API</blockquote><br class=""></div><div>Is it really so heavy-weight? Obviously it's a bit more effort than three dots, but it's also declaring an explicit type for your function, which it can also handle directly in addition to variadic calling.</div><div><br class=""></div><div>In my experience the use of @noescape closures is much, much more common than variadics, yet no-one seems that desperate to introduce a custom syntax just to make them more lightweight to declare. In fact I could probably count the number of variadic functions I've seen or used in Swift on one hand, but I use and benefit from @noescape daily without ever feeling the attribute has been a burden to declare. This is after all a declaration-site change, anyone actually using variadics shouldn't notice much of a difference except where the ambiguity issue strikes, but then that's a problem for any array-passing extension to variadics I think.</div></body></html>