It is definitely not hard to solve any issues here (if you consider only the basic variadics). Int... is nothing more than [Int], so essentially<div><br></div><div>   func doSomething(args : Int...)</div><div><br></div><div>is also just</div><div><br></div><div>   func doSomething(args : [Int])</div><div><br></div><div>We just have to think of it like some form of function overloading and the compiler can automatically handle that.</div><div><br></div><div>As for enabling usage of other types as the result of variadics, I don&#39;t see how that can be a benefit (unless you&#39;re just trying to write little bit less on your own code). You would have to add some extra code on the compiler to check whether you can use that type for your variadics argument and may incur in more changes to enable handling different classes possible. I would also expect to be able to use dictionaries as variadics with this syntax, and that would be confusing too.</div><div><br></div><div>Should this pass like it is, it would not surprise me if my apps take more time to compile. Now, if the problem is just being able to pass an array to a variadics argument, my solution is cleaner, incur in less changes to the language and is backwards compatible.</div><div><br></div><div>L<br><div><br>On Friday, 8 July 2016, Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 8 Jul 2016, at 10:31, Pyry Jahkola &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;pyry.jahkola@iki.fi&#39;);" target="_blank">pyry.jahkola@iki.fi</a>&gt; wrote:</div><div><div dir="auto"><div><div><br></div><div>If you take this function for example,</div><div><br></div><div>    func printThem(@variadic _ values: [Any])</div><div><br></div><div>then what would `values` be in the following calls, and why?</div><div><br></div><div>    printThem() // clearly []</div><div>    printThem(1) // clearly [1]</div><div>    printThem(1, 2) // clearly [1, 2]</div><div>    printThem([1], [2]) // clearly [[1], [2]]</div><div>    printThem([]) // [] or [[]], which one?</div><div>    printThem([1]) // [1] or [[1]]?</div><div>    printThem([1, 2]) // [1, 2] or [[1, 2]]?</div></div></div></div></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><div><div dir="auto"><div><div>I think it would be less painful a change (i.e. can be delayed past Swift 3) if we just augment what we have (the `...` argument declaration syntax) with a way to expand an Array in place of a variadic argument:</div><div><br></div><div>    func printThem(_ values: Any...)</div><div><br></div><div>    printThem(1) // values == [1]</div><div>    printThem([1]) // values == [[1]]</div><div>    // Possible expansion postfix syntax:</div><div>    printThem([1]...) // values == [1]</div><div>    // Expanding a non-array sequence:</div><div>    let things: Set&lt;Int&gt; = [1, 2, 3]</div><div>    printThem(Array(things)...)</div></div></div></div></blockquote></div><br><div>Good point, but actually these don&#39;t seem mutually exclusive; the three problem examples you gave could be resolved either by requiring the extra set of square brackets for clarity, and/or some kind of expansion like you suggest, either an operator or even possibly repurposing the attribute at the call-site for consistency. For example:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>printThem([1])<span style="white-space:pre-wrap">        </span>// warning, ambiguous</font></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>printThem([[1]])// non-variadic</font></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>printThem(@variadic [1]) // absolutely definitely 100% a variadic call</font></div><div><font face="Monaco"><span style="white-space:pre-wrap">        </span>printThem([1],) // alternative to an operator/attribute for variadic disambiguation?</font></div><div><br></div><div>Thoughts?</div><div><br></div><div><br></div><div><div></div></div><blockquote type="cite"><div><div>On 8 Jul 2016, at 10:42, Tino Heth &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;2th@gmx.de&#39;);" target="_blank">2th@gmx.de</a>&gt; wrote:</div><div>I&#39;m not sure if the timing of this proposal is coincidence (I recently revived a discussion to remove variadics)</div></div></blockquote><br><div>It is definitely not a coincidence ;)</div><div>I participated in the discussion on removal in the past and actually posted a preliminary version of this there, so the recent posts reminded me to put it into a proper proposal. Personally like some I&#39;d just remove the feature completely, but it seems enough people want to keep it that it&#39;s worth exploring alternatives as there seems a fairly even mix of those for and against the feature.</div></div></blockquote></div></div><br><br>-- <br>L<br>