> On May 3, 2016, at 10:06 PM, Robert Widmann <[email protected]> wrote: > > Once-and-for-all implementations come in many flavors. For now, we have > clear interest in making a limited subset of possible tuples properly > Comparable. This will also make it easier to implement extensions to > specific arities now and serve as a base for variadic generics if that is the > path we take. I could certainly see Future Swift™ allowing this to sit > side-by-side with the finite version in this proposal, couldn't you? > > extension (T...) : Equatable where T.Element : Equatable { } > > func == <T : Equatable>(l : (T...), r : (T...)) -> Bool { /* .. */ }
One problem with introducing variadics later would be that, if we ship the specific-arity conformances in an ABI-stable standard library, we're stuck carrying those extensions around forever for backward compatibility. -Joe > ~Robert Widmann > > 2016/05/04 0:54、Joe Groff <[email protected]> のメッセージ: > >> >>> On May 3, 2016, at 9:52 PM, Robert Widmann <[email protected]> wrote: >>> >>> Trouble is that I don't want variadic generics without corresponding >>> support from the type system which is untenable without HKTs (see last >>> paragraph of proposal). C++'s variadic implementation of std::tuple is not >>> elegant to my mind, and would have no place in a library I could think of >>> writing. >> >> I think we'd keep tuples as a builtin type. Variadics would just let you >> implement Equatable/Hashable/etc. once for all tuple arities. I don't see >> why we'd need HKTs for that. >> >> -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
