> On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution > <swift-evolution@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
