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

[Jordan Rose]

> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas <mailing at xenonium.com> wrote:
> 
> Just a though, but why sealed classes have to be completely unsubclassable ?
> 
> Wouldn't it be possible to allow the user to subclass sealed class, but deny overriding of any public member.
> 
> I see a use case where a user want to extends an existing model by adding new properties and new methods to an object but can’t use composition because doing that will prevent to pass that object to the framework that expect the base object.
> 
> That would let user override existing class to extends them, but should not cause any side effect in the way the class should behave, and so would not affects preconditions and postconditions, and should not prevent optimization in whole module compilation, as the methods of the base class are considered final outside of the module.
> 
> Of course, it will introduce some fragility in the library, as adding new methods may conflict with user subclass methods, but no more than what would append if the user write extension to add new methods to the model.

DaveA and I actually talked about this, and IIRC we decided it was completely safe semantically, and only left a few optimization opportunities on the table (things like knowing what a deinitializer might or might not do). However, we felt it was a more complicated model that still ended up with the “de facto sealed” case of all initializers being non-public, and so it wasn’t worth stopping at that point in the design space.

(It was a while ago, so I might have forgotten something else relevant.)

Jordan