> On May 29, 2016, at 2:39 AM, Daniel Vollmer via swift-evolution > <[email protected]> wrote: > > >> On 29 May 2016, at 02:33, Austin Zheng <[email protected]> wrote: >> >>> - 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. > > The C++ pack expansion rules > http://en.cppreference.com/w/cpp/language/parameter_pack in the most basic > case expand out and separate with commas, e.g. > > pack = (a, b, c) > foo(pack …) => foo(a, b, c) > > But then pattern (i.e. the part to the left of …) may also be more > complicated, e.g. > > foo(pack++) … => foo(a++), foo(b++), foo(c++) > > The fold expressions then “only” replace the commas separating instantiations > of the pattern with a different “operator” (and special associated rules for > the null element). > > And although I really (ab-)use this feature in C++, I’m not entirely sure > whether this sort of thing wouldn’t be more suited to a macro(-ish) system > than trying to tie it to generics? That said, of course expansion has to be > possible inside Generic<Pack …>, but I don’t see why it wouldn’t be.
I think single-function application is a common enough case that it should be handled, without the generality of a macro system. Not sure how much further it should be taken, especially in a v1. > >>> - 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: >> - 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). >> 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. > > I’d think something like (explicit) splat at the call-site with what I’d > imagine would be a few different variants would be the cleanest: > - #anonymous_splat: takes tuple with or without labels and expands according > to pattern ignoring function argument labels > - #named_splat: takes tuple with or without labels and an optional second > tuple type (default to the type of the first tuple) of matching size from > which it takes the names and expands the values in the first tuple as the > names (labels) from the second type. > - …? As I mentioned in my email to Matthew, Swift already has a way to fully qualify a method name, including the "argument labels". if that fully qualified name is used, IMO the parameter labels in the tuple are redundant and should be optional/ignored. > >> - 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). > > Yeah, the expansion from tuple to args has to happen at the call site, I > think. > > Is it possible to have a Tuple containing an `inout` reference (i.e. I want > reference behaviour for this tuple member)? I tried this last night; it doesn't seem to be possible. > > 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
