It may be farther reaching, but it's quite salient. Completing genetics is a Swift 4 focus, and protocol conformance and extensions of structural types may well have ABI implications, which would make it a phase 1 priority.
Recall that equality for tuples of Equatables is only defined up to an arity of 6, and that it was implemented in that way as a stopgap. With a plausible definitive solution in scope for Swift 4, it seems less than ideal to propose entrenching the stopgap measure by making it even more elaborate. On Sun, Oct 16, 2016 at 19:47 Haravikk via swift-evolution < [email protected]> wrote: > > On 16 Oct 2016, at 11:55, Karl <[email protected]> wrote: > > > On 16 Oct 2016, at 00:33, Haravikk via swift-evolution < > [email protected]> wrote: > > > On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky < > [email protected]> wrote: > > Tuples cannot conform to protocols, so despite the existence of an “==” > operator for certain tuples, no tuple conforms to Equatable. > > This is problematic, because it means that a function which takes a > generic Equatable parameter cannot be called with a tuple argument, even > though an applicable “==” operator exists. > > (Ditto for “Comparable”, *mutatis mutandis*.) > > Nevin > > > Yeah, since the operators are implemented though perhaps some kind of > magic can be used? It seems strange that the following is valid: > > struct Foo : Equatable { let value:(Int, Int) } > func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value } > > Yet tuples can't just be Equatable etc. But I'm wondering whether that > falls into separate issue territory, such that it should be done first as > its own proposal? > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > Tuples are non-nominal (named) types, and that’s why they can’t conform to > protocols. There is something in the generics manifesto about possibly > allowing them to do that in the future, though: > > > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types > > Extensions of structural types > > Currently, only nominal types (classes, structs, enums, protocols) can be > extended. One could imagine extending structural types—particularly tuple > types—to allow them to, e.g., conform to protocols. For example, pulling > together variadic generics, parameterized extensions, and conditional > conformances, one could express "a tuple type is Equatable if all of its > element types are Equatable": > > extension<...Elements : Equatable> (Elements...) : Equatable { // extending > the tuple type "(Elements...)" to be Equatable > } > > - Karl > > > Yeah, but that's much further reaching overall; I'm wondering whether it's > okay to just call tuples of Equatable types Equatable for the purposes of > getting them as enum raw values? I'll maybe put some discussion of timing > and other issues into the proposal for this, to keep it open ended. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
