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 > > -Chris > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution