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

[Károly Lőrentey]

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 
>> <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.

"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