<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="">Hi Dimitri,<div class=""><br class=""></div><div class="">I think this is a desirable feature, but nobody has got around to designing and implementing it yet.</div><div class=""><br class=""></div><div class="">Another case where it comes up is initializer inheritance. Suppose I have:</div><div class=""><br class=""></div><div class="">class Base {</div><div class=""> init(x: Int…) {}</div><div class="">}</div><div class=""><br class=""></div><div class="">class Derived : Base {</div><div class="">}</div><div class=""><br class=""></div><div class="">Currently, Derived does not inherit Base.init(), because we have no way to synthesize the AST which performs this ‘forwarding’.</div><div class=""><br class=""></div><div class="">In fact, if somebody wanted to attempt an implementation of this, handling this case first would be easier because then you can implement the AST node for splatting a vararg and get it working without worrying about parser changes (probably you can shoehorn it into TupleShuffleExpr). Then after a design for the syntax has been accepted, add the parser support on top.</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 3:51 PM, Dimitri Racordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hello everyone.
<div class=""><br class="">
</div>
<div class="">I understand that topic has already been discussed in the past, but I failed to get any information on its current state of affairs.</div>
<div class=""><br class="">
</div>
<div class="">I guess the subject of this mail is explicit, but to make sure I’m clear, here's a small snippet that illustrates the problem:</div>
<div class=""><br class="">
</div>
<div class=""><font face="Consolas" class="">func f(args: Int…) {</font></div>
<div class=""><font face="Consolas" class=""> // Some implementation ...</font></div>
<div class=""><font face="Consolas" class="">}</font></div>
<div class=""><font face="Consolas" class="">// Now it's impossible to call f without explicitly naming its parameters.</font></div>
<div class=""><br class="">
</div>
<div class="">For many use-cases, this problem can be solved by overloading <font face="Consolas" class="">f</font> so that it explicitly accepts an array.</div>
<div class=""><br class="">
</div>
<div class=""><font face="Consolas" class="">func f(_ args: [Int]) {</font></div>
<div class=""><font face="Consolas" class=""> // Some implementation ...</font></div>
<div class=""><font face="Consolas" class="">}</font></div>
<div class=""><font face="Consolas" class=""><br class="">
</font></div>
<div class=""><font face="Consolas" class="">func f(_ args: Int…) {</font></div>
<div class=""><font face="Consolas" class=""> f(args)</font></div>
<div class=""><font face="Consolas" class="">}</font></div>
<div class=""><br class="">
</div>
<div class="">Some people also advocate (myself generally included) that one should prefer the signature explicitly marking <font face="Consolas" class="">args</font> as an array, as the syntactic overhead of wrapping the arguments with “<font face="Consolas" class="">[]</font>”
when calling <font face="Consolas" class="">f</font> is arguably bearable. However, in some other situations, this approach might not be applicable. For instance, one may simply not be able to modify the original function. Another use-case may be a function
that should forward its own variadic parameters.</div>
<div class=""><br class="">
</div>
<div class="">In a variety of other languages, there exists a way to do this. For instance, Python can “unpack” (or splat) a list into function arguments by prefixing it with <font face="Consolas" class="">*</font>:</div>
<div class=""><font face="Consolas" class=""><br class="">
</font></div>
<div class=""><font face="Consolas" class="">def f(*args):</font></div>
<div class=""><font face="Consolas" class=""> # Some implementation …</font></div>
<div class=""><font face="Consolas" class=""><br class="">
</font></div>
<div class=""><font face="Consolas" class="">f(*[1, 2, 3]) # == f(1, 2, 3)</font></div>
<div class=""><br class="">
</div>
<div class="">I was wondering if such feature could be supported by Swift, and if not, why.</div>
<div class=""><br class="">
</div>
<div class="">Syntactically, I like the use of “<font face="Consolas" class="">…</font>”, which would mirror function signatures:</div>
<div class=""><br class="">
</div>
<div class=""><font face="Consolas" class="">f(…[1, 2, 3]) // == f(1, 2, 3)</font></div>
<div class=""><br class="">
</div>
<div class="">Thanks.</div>
<div class=""><br class="">
</div>
<div class="">--</div>
<div class="">Dimitri Racordon</div>
<div class=""><br class="">
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>