Hi Andrew, Implicitly making Tuples Hashable should be its own proposal. Take a look at the Equable Tuple proposal as a template. https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
Thanks > On May 9, 2017, at 3:45 PM, Andrew Bennett via swift-evolution > <[email protected]> wrote: > > You state that you will not synthesise conformance for tuples, I agree with > this, but if a struct or enum holds a tuple it would be nice if it could be > hashed if its members are all hashable. > > struct A { > var a: Int, b: Int, c: Int > } > > struct B { > var tuple: (a: Int, b: Int, c: Int) > } > > I'd consider these two to be equivalent as far as this proposal is concerned, > it would be nice if the proposal made that explicit. > > > On Tue, May 9, 2017 at 7:17 AM, Tony Allevato via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On Mon, May 8, 2017 at 2:11 PM Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: >> On May 8, 2017, at 4:02 PM, Tony Allevato <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sat, May 6, 2017 at 4:17 PM Chris Lattner <[email protected] >> <mailto:[email protected]>> wrote: >> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>> Can the opt-in conformance be declared in an extension? If so, can the >>> extension be in a different module than the original declaration? If so, >>> do you intend any restrictions, such as requiring all members of the type >>> declared in a different module to be public? My initial thought is that >>> this should be possible as long as all members are visible. >>> >>> Declaring the conformance in an extension in the same module should >>> definitely be allowed; >> >> Please follow the precedent of the Codable proposal as closely as possible. >> If you’d like this to be successful for Swift 4, you should look to scope it >> as narrowly as possible. Because it is additive (with opt-in), it can >> always be extended in the future. >> >>> I believe this would currently be the only way to support conditional >>> conformances (such as the `Optional: Hashable where Wrapped: Hashable` >>> example in the updated draft), without requiring deeper syntactic changes. >> >> This proposal doesn’t need to cover all cases, since it is just sugaring a >> (very common) situation. Conditional conformances to Hashable could be >> written manually. >> >>> I'm less sure about conformances being added in other modules, >> >> It is a bad idea, it would break resilience of the extended type. >> >>> But after writing this all out, I'm inclined to agree that I'd rather see >>> structs/enums make it into Swift 4 even if it meant pushing classes to >>> Swift 4+x. >> >> Agreed, keep it narrow to start with. >> >> Also, I don’t know how the rest of the core team feels about this, but I >> suspect that they will be reticent to take an additive proposal at this late >> point in the schedule, unless someone is willing to step up to provide an >> implementation. >> >> That someone is me :) I have a branch where it's working for enums (modulo >> some weirdness I need to fix after rebasing a two-month-old state), and >> adapting that logic to structs should hopefully be straightforward after >> that. Going with the more narrowly-scoped proposal and making conformances >> explicit simplifies the implementation a great deal as well (I was >> previously blocked with recursive types when it was implicit). >> >> Thanks for the feedback—after consideration, I've pulled classes out of the >> proposal completely (even non-final) and mentioned the other limitations so >> we'd have a record of what was discussed in this thread. >> >> I've created a PR for the proposal text, in the event that the core team is >> interested in moving this forward: >> https://github.com/apple/swift-evolution/pull/706 >> <https://github.com/apple/swift-evolution/pull/706> > Thanks for continuing to push this forward Tony! The current proposal looks > like the right approach for getting this into Swift 4. > > I only have one question which I will present with an example: > > protocol Foo: Equatable {} > protocol Bar: Hashable {} > > struct FooType: Foo {} > struct BarType: Bar {} > > Do FooType and BarType receive synthesis? > > Great question! Yes they should. It's "explicit" transitively since the > answer to "does FooType/BarType conform to Equatable/Hashable?" is still > "yes". (And I've confirmed that my prototype handles this case.) > > This is especially helpful since Hashable extends Equatable, so a user only > needs to list conformance to the former to get correctly synthesized > implementations of both, which helps to guarantee that they're implemented > consistently with respect to each other. > > > >> >> >> >> -Chris >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > 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
