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