[swift-evolution] Variadic generics discussion

[Austin Zheng]

> On Jun 1, 2016, at 6:18 AM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On May 31, 2016, at 6:49 PM, Austin Zheng <austinzheng at gmail.com> wrote:
>> 
>> I agree that this is a better design for Swift than the monstrosity I started out with.
>> 
>> The "biggest" technical challenge I see is being able to type a reduction sort of operator on a heterogenous tuple based on on whatever protocols and constraints are common to its constituent members. For example:
>> 
>> // Every Tn in T... is Fooable and Barrable
>> let x : (T...)
>> reduce(x, reducer, startingValue)
>> 
>> func reducer<X : ???>(startingValue: U, eachMemberOfT: X) -> U { ... }
>> 
>> How do we bound ??? such that 'reducer' is useful while still being statically type sound? Honestly, that's the most interesting question to me. Generalized existentials might help with that.
> 
> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, protocol<Fooable, Barrable>) -> ()?

I feel like I might be overthinking this. The tightest sound bound is protocol<Fooable, Barrable> (or <T : Fooable where T : Barrable>, and the loosest bound is Any (or <T>), but it would be good to have a notion of ordering other bounds so that functions with more lenient bounds for which all the requirements are satisfied by the tuple members (e.g. protocol<Fooable>, not protocol<Fooable, Baz>) are admitted. This would become more complex with associated types and constraints thereof, where ordering doesn't just mean "at least some of the protocols the variadic parameter type bounds are required to conform to, but not any new ones".

> 
>> Other questions (inherent to any proposal) would be:
>> 
>> - How do we resolve the impedance mismatch between tuples and function argument lists? Is it even worth trying to resolve this mismatch, given that argument lists are intentionally not intended to mirror tuples?
> 
> The impedance mismatch between function arguments and tuples is superficial. You ought to be able to splat and bind tuples into function arguments, e.g.:
> 
> 	let args = (1, 2)
> 	foo(bar:bas:)(args...)
> 
> 	func variadicFn<T: Runcible...>(_ args: T...) { ... }

I agree, I was thinking more of things like inout and default parameters. But that splat/bind notation should be enough for the majority of use cases.

> 
>> - As you said, how do variadic generics work in the 0- and 1-member cases?
> 
> What problem are you referring to?
> 

How does a type with zero type parameters work? I guess all the variadic tuples in question could just be the empty tuple.

Would there be tuple operations that work on variadic tuples which would break down in the 1-ple case (where the item isn't a tuple anymore, but a regular value)?

As Brent mentioned, having base cases for the 0 and 1-arity cases defines this problem away. so it's not really a big deal.

> -Joe
>