> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas <mail...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
