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

[Taras Zakharko]

> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree with Kevin Ballard on being open by default for methods/ properties http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/ <http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/>
> 
> If we are open by default for methods/properties then we could simplify things by just using final for methods that need to be sealed; I don’t see the need to have sealed methods/properties outside of the module ONLY. 

The proposal (and additional comments) explain this point fairly well. Usually, it makes sense to be overridable only for few select members — and compiler can’t easily figure out which entry points these are as the API invariants are not explicit. By making members sealed by default, the API contracts are made more clear.  Second (and a very important reason) is performance — if everything is open by default, the compiler can’t devirtualize property accessors even though it would be appropriate most of the time. The compiler can infer the ‚final‘ status of definitions within a module easily and optimise accordingly, which wot work if these definitions can be overridden externally. To put it differently, its much easier for the compiler to determine what can be safely considered final than what can be safely considered sealed. The design choices in the proposal follow naturally from these considerations. 

The final keyword still has its use, although I think its utility will be somewhat diminished after this proposal. You can still use it for things that can’t be overridden internally. Like classes that are intended only to be used as ‚structs  with reference semantics‘. 

— T



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/4b77c72a/attachment.html>