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