> On Jun 1, 2016, at 9:35 AM, Austin Zheng <[email protected]> wrote: > > >> 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)?
A regular value is a 1-tuple of itself. In the type system, we know what abstraction level a value expects to work at. It shouldn't be a problem for a variadic type parameter to be bound to 0, 1, or more types. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
