> On Jun 1, 2016, at 6:18 AM, Joe Groff <[email protected]> wrote:
>
>
>> On May 31, 2016, at 6:49 PM, Austin Zheng <[email protected]> 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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
