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 < swift-evolution@swift.org> wrote: > > > On Mon, May 8, 2017 at 2:11 PM Matthew Johnson <matt...@anandabits.com> > wrote: > >> On May 8, 2017, at 4:02 PM, Tony Allevato <tony.allev...@gmail.com> >> wrote: >> >> On Sat, May 6, 2017 at 4:17 PM Chris Lattner <clatt...@nondot.org> wrote: >> >>> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution < >>> swift-evolution@swift.org> 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 >> >> >> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution