[swift-evolution] Variadic generics discussion

[Austin Zheng]

> On May 29, 2016, at 2:39 AM, Daniel Vollmer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 29 May 2016, at 02:33, Austin Zheng <austinzheng at gmail.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution