[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Riley Testut]

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 <swift-evolution at swift.org> wrote:

>> On Jul 14, 2016, at 2:39 PM, Chris Lattner <clattner at apple.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution