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

[Brent Royal-Gordon]

> On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> Introducing "dynamic" or some other keyword to mark explicitly methods
>> that should be overriden is just the same "open" with sealed methods
>> by default would mean for public methods so it makes no difference to
>> me.
> 
> "dynamic" is already in the language. It changes method dispatch to use Objective-C style message passing, enabling advanced techniques based on the dynamic runtime, such as method swizzling or KVO. Since it already exists, I'm not arguing for its introduction; I merely want it integrated into the proposal, in order to keep the language coherent.

I would prefer not to ascribe overridability semantics to `dynamic`. I see `dynamic` as a hint to the compiler that something *outside of normal, safe Swift code* may cause this entity's implementation to change. A `dynamic final` member is a perfectly coherent concept: Formally, nothing is allowed to override this member, but in practice, something may change it behind the compiler's back.

-- 
Brent Royal-Gordon
Architechies