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

[Brent Royal-Gordon]

> On Jul 19, 2016, at 4:00 AM, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:
> 
> "dynamic final" is prohibited by the current version of compiler.

Huh, I didn't know that. I don't agree with that design.

(However, I do notice that a `final` class can have `dynamic` members.)

> Can you provide an example of a problem that would be solved by allowing it?

In our current Objective-C world, the obvious example would be an NSObject subclass with a property that should not be overridden (so you want to mark it `final`), but which participates in KVO (so in fact Foundation will use the Objective-C runtime to invisibly subclass the class, override the setter, and change the type of the instance to the subclass). I believe it makes perfect sense to declare such a property `dynamic final`; the Objective-C-level overriding performed by Foundation is an implementation detail, and does not change the fact that you should never declare an override of that property.

It's not really clear how `dynamic` would be used without Objective-C, but I could imagine analogous situations, like an ORM implementing Core Data-style faults using dirty, low-level class-changing hacks. A class that was *semantically* `final`, and thus ought to be eligible for static dispatch, might thus require dynamic dispatch anyway.

-- 
Brent Royal-Gordon
Architechies