[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Brent Royal-Gordon brent at architechies.com
Mon Jul 18 03:27:00 CDT 2016

> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution <swift-evolution at swift.org> wrote:
>> Is there a summary somewhere of the motivation for allowing methods to be declared non-overridable within open classes?
> Because 1) someone woke up one morning and thought it would be great 2) it goes into the direction of making swift a language for non programmers 3) the core team wants it

Laurent: This is not a fair characterization of the actual position of the proposal's supporters. If you can't be civil about this topic, perhaps you shouldn't be discussing it at all.

Garth: I think it's implicit in the reasons to prevent subclassing. The mere fact that a class allows subclassing doesn't necessarily mean that every member in it is designed to be subclassed. Consider `UIViewController`: It's obviously designed to be subclassed, and some methods in it (such as `loadView`) are intended to be overridden, but others (such as `loadViewIfNeeded`) are *not* intended to be overridden.

Brent Royal-Gordon

More information about the swift-evolution mailing list