<div dir="ltr">I would also be supportive of removing varargs for now, in favor of a rethought design when generics are completed.<div><br></div><div>In their current form, varargs are fairly limited—because they're mapped onto an array, the argument types must be homogeneous, so either your function can only usefully take a single type of argument, or you potentially lose information because they have to be upcast to a common supertype or Any in order to build the array.</div><div><br></div><div>I'm not convinced that varargs produce code that is much cleaner than the array version. Is this:</div><div><br></div><div> String(format: "%@ is %d years old", name, age)</div><div><br></div><div>that much cleaner than:</div><div><br></div><div> String(format: "%@ is %d years old", arguments: [name, age])</div><div><br></div><div>Perhaps slightly, but I'm not sure it's worth the special case. The function implementor can even get rid of the second argument name if they wanted to make it cleaner. And if the function you're calling takes varargs as its sole argument, the only difference is two brackets.</div><div><br></div><div>Varargs in their current form seem like a historical vestige from languages like C and Java where there was no syntax to cleanly create an anonymous array literal. Swift doesn't have that limitation.</div><div><br></div><div>That being said, where varargs *do* become considerably more useful is when generics are completed and you can have variadic type argument lists. But in that case, the implementation is completely different because (if Swift followed C++'s design) you'd be working with a parameter pack instead of an array, and you would have operations that let you manipulate that pack while preserving the compile-time type information of those arguments.</div><div><br></div><div>IMO, handling it that way seems like a better approach than trying to graft something to bridge varargs and arrays.</div><div><br></div><div dir="ltr"><div dir="ltr"><div><br><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016 at 11:14 AM Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Justin Jia via swift-evolution <swift-evolution@...> writes:<br>
<br>
><br>
> Hi!Currently, we can’t call a variadic function with an array of arguments.<br>
<br>
IMO, this would be a useful addition. Here are my thoughts on the thread so<br>
far as an imaginary Q&A.<br>
<br>
"Why not remove vararg instead?"<br>
<br>
As others have mentioned, this feature enable us to write cleaner code. I<br>
first learned to appreciate it in C, where some books would introduce it as the<br>
way to implement printf(). I really prefer not to create an array on unrelated<br>
items just to print() them in Swift.<br>
<br>
"Will it be useful in real life?"<br>
<br>
If we keep vararg, then enhancing it with a splat feature will make it far<br>
more useful than it is today. One of my colleague (hi Scott!) encountered its<br>
limits just last week: once the varadic argumntes becomes an array, there's no<br>
way to get them "back" as arguments. This becomes an issue if our function<br>
needs to forward part of its received arguments recursively to itself. Either<br>
of the following would be great:<br>
<br>
func foo(a: Int...) {<br>
if !a.isEmpty() {<br>
apply(foo, a.dropFirst()) // imaginary apply function.<br>
foo(a: #splat(a.dropFirst())) // imaginary splat, syntax TBD.<br>
}<br>
}<br>
<br>
<br>
Therefore, +1.<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div></div></div></div>