> On Jul 19, 2016, at 4:00 AM, Károly Lőrentey via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
