FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts:
• Open keyword is significantly better. • Members should be *open* by default, and final should be opt-in. If you're opening up a class for subclassing, my gut says you should allow the client to do as they wish. If only one or two methods should be overridable, I think delegation (via protocols) is a much better solution. • I feel like final and open are now *almost* on the same axis, but not quite; open controls subclassability outside module, but final controls it for both. Why not use access control modifiers, such as: - public(open) - internal(open) (default) - fileprivate(open) - private(open) = final Then, we could remove the "final" keyword from the language completely, and use access control as normal. I feel like this unifies everything much better (private(open) does seem a little weird though). On Jul 15, 2016, at 1:27 AM, Brent Royal-Gordon via swift-evolution <[email protected]> wrote: >> On Jul 14, 2016, at 2:39 PM, Chris Lattner <[email protected]> wrote: >> >> asks the community for an in-depth discussion of the secondary points of the >> proposal: does it make sense to require every member to be marked as >> “overridable” in order to be overridden by an open subclass outside of the >> current module? > > To be clear: You want this discussion to happen in the next review thread, > rather than in this thread? > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
