<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 7, 2016, at 1:10 AM, Ricardo Parada via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class="">In the motivation section <b class="">performance</b> is also mentioned as driving this proposal. However I don't see any study that supports that. I would like to see that. This should not be taken lightly. </div></div></div></div></blockquote><div><br class=""></div><div>There kind of was a discussion on this.</div><div><br class=""></div><div>John McCall (<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/22111" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/22111</a>)</div><div><br class=""></div><div><div class=""></div><blockquote type="cite" class=""><div class="">Finally, the specific form of devirtualization in question here, where a method is proven to never be overridden (again, very common for accessors!), can have a significant impact separate from any calls because the method essentially no longer needs to be virtual. That is, it can be removed from the virtual method tables completely, and we may be able to completely avoid emitting it. That shrinks the size of global memory (and the binary), decrease the amount of work that has to be done at load-time, and improves locality within the virtual table.</div></blockquote></div><div><br class=""></div><div>I remember that he's mentioned some benchmark final vs. non-final where the difference was in some cases staggering. In general, when you enable whole-module optimization, the compiler can treat all classes within the module as final and optimize mainly accessing properties since they are then known to be final...</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div><div class="">Let's imagine that performance is important for a library that is heavily used and that the classes are not the type that you usually override. Wouldn't we be better served by being able to seal the class, i.e. "<b class="">public sealed class Foo</b>" and then for the methods / properties that are clear extension points should be flagged <b class="">overridable</b>. I would prefer something like that. And I think it would be more intuitive. </div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> * Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""></div></blockquote><div class=""><br class=""></div>No. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> * Does this proposal fit well with the feel and direction of Swift?</span><br class=""></div></blockquote><div class=""><br class=""></div><span style="background-color: rgba(255, 255, 255, 0);" class="">I think it is counter-intuitive. I don't think that reading "<b class="">public class Foo</b>" would make anyone think that Foo is non-subclassable. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">On the other hand, reading "<b class="">public class sealed Foo</b>" would suggest to the reader that the class can be overridden but only the methods that are flagged as <b class="">overridable</b>. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">If we wanted to prohibit overriding then we could use "<b class="">public final class Foo</b>" without any extension points. Then nobody would be able to subclass and it would be an error to try to flag a method / property as overridable. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br class=""></div></blockquote><div class=""><br class=""></div>I don't recall having seen this behavior in the languages that I have worked with. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br class=""></div></blockquote><br class="">I read the whole proposal and have been thinking about the implications for a few hours. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class="">More information about the Swift evolution process is available at</span><br class=""><span class=""></span><br class=""><span class=""> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br class=""><span class=""></span><br class=""><span class="">Thank you,</span><br class=""><span class=""></span><br class=""><span class="">-Chris Lattner</span><br class=""><span class="">Review Manager</span><br class=""><span class=""></span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution-announce mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution-announce@swift.org" class="">swift-evolution-announce@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" class="">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a></span><br class=""></div></blockquote></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>