Thanks for your feedback! > On May 28, 2016, at 3:21 PM, Daniel Vollmer via swift-evolution > <[email protected]> wrote: > > 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: > - I’d prefer head + tail over first + rest, but that’s pretty irrelevant
It looks like C++ uses head/tail, so we should too. > - 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. 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 (https://dlang.org/variadic-function-templates.html <https://dlang.org/variadic-function-templates.html>), etc.) 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. > - 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? I think so. I would expect you to be able to do something like this with the given semantics: func foo<...T, ...U>(...args : T..., ...moreArgs: (U...)) { /* */ } You have count(T) + 1 arguments, where the last argument is a tuple with count(U) members. > - 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? This is definitely something that needs to be worked out. > - 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? There are a couple of issues with implementing this using only tuples: - 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. - 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 (https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md>). 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. - 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). 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. > > Daniel. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
