<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="">Thanks for your feedback!<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 28, 2016, at 3:21 PM, Daniel Vollmer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><br class="">I’ve only taken a short glance at this (and just like the proposal, I’m damaged by C++11, so my opinion is biased), so here are some thoughts:<br class="">- I’d prefer head + tail over first + rest, but that’s pretty irrelevant<br class=""></div></div></blockquote><div><br class=""></div><div>It looks like C++ uses head/tail, so we should too.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Often in C++, the need for recursion when using first + rest goes away when you can index into parameter packs (e.g. using integer_sequence) or have fold expressions.<br class=""></div></div></blockquote><div><br class=""></div><div>My inclination is to keep things simple for now; more capabilities can be added in the future, when it becomes clearer what sort of compile-time metaprogramming story Swift wants to support. (Things like const expressions, compile-time control flow like described here for D's version of this feature (<a href="https://dlang.org/variadic-function-templates.html" class="">https://dlang.org/variadic-function-templates.html</a>), etc.)</div><div><br class=""></div><div>But a fold expression sort of construct is almost certainly worth considering in an initial proposal. It would, for example, considerably save you code size if you were to implement an (e.g.) equality between 72-ples.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">- It might occasionally be useful to have multiple parameter packs (or argument packs). In C++ you can do that by wrapping it in a tuple. Do we have / need such an escape hatch?<br class=""></div></div></blockquote><div><br class=""></div><div>I think so. I would expect you to be able to do something like this with the given semantics:</div><div><br class=""></div><div>func foo<...T, ...U>(...args : T..., ...moreArgs: (U...)) { /* */ }</div><div><br class=""></div><div>You have count(T) + 1 arguments, where the last argument is a tuple with count(U) members.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- I have an argument pack. How would I apply a function taking a single argument to each element in the pack? Go via the tuple?<br class=""></div></div></blockquote><div><br class=""></div><div>This is definitely something that needs to be worked out.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">- Why is this a separate thing from Tuple itself? It feels so similar; I can convert between them, so why do I need this other thing?<br class=""></div></div></blockquote><div><br class=""></div><div>There are a couple of issues with implementing this using only tuples:</div><div><br class=""></div><div>- There needs to be a way to distinguish between passing a tuple containing n elements to a function, and passing n arguments to that function via a tuple. Right now Swift makes no distinction between a 1-ple and the element contained within it.</div><div><br class=""></div><div>- Using tuples for everything requires functions written to be used with variadic generics to specifically take a single tuple as an argument, or to bring back a redesigned version of the magical tuple splat functionality (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md</a>). A value pack isn't a tuple and doesn't have to worry about whether or not argument labels should match up with tuple member labels, etc.</div><div><br class=""></div><div>- Tuples don't allow for generic functions that take a varying number of arguments, unless you want to write them as functions that take a variably sized tuple (see the "foo()" example above).</div><div><br class=""></div><div>However, if there is a way to define these problems away I would be all too happy to see a proposal that exclusively deals with variadic tuples.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Daniel.<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></body></html>