<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 16, 2016, at 9:18 AM, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">I agree with Kevin Ballard on being open by default for methods/ properties <a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/23467/</a></div><div class=""><br class=""></div><div class="">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. </div></div></div></div></blockquote><br class=""></div><div class="">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. </div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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’. </div></div></div></blockquote>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.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">— T</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""></body></html>