On 2016-07-19 00:46:21 +0000, Brent Royal-Gordon via swift-evolution said:
On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution
<[email protected]> 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.
"dynamic final" is prohibited by the current version of compiler. Can
you provide an example of a problem that would be solved by allowing it?
--
Károly
@lorentey
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
