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

[Jose Cheyo Jimenez]

> On Jul 16, 2016, at 9:18 AM, Taras Zakharko <taras.zakharko at uzh.ch> wrote:
> 
> 
>> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto: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 compiler is welcome to optimize my sealed classes but once I slap `open` on the class, I am telling the compiler that I am not interested in the automatic optimizations imo.

> 
> 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’. 
struct with reference semantics is what sealed classes are, but once I make the class open, i’d like for it to act like a regular subclassable class.


> 
> — T
> 
> 
> 

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