<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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.&nbsp;</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. &nbsp;That is, it can be removed from the virtual method tables completely, and we may be able to completely avoid emitting it. &nbsp;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 &nbsp;by being able to seal the class, i.e. "<b class="">public sealed class Foo</b>" &nbsp;and then for the methods / properties that are clear extension points should be flagged <b class="">overridable</b>. &nbsp;I would prefer something like that. And I think it would be more intuitive.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> &nbsp; &nbsp;* Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""></div></blockquote><div class=""><br class=""></div>No.&nbsp;</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> &nbsp; &nbsp;* 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.&nbsp;I don't think that reading "<b class="">public class Foo</b>" would make anyone think that Foo is non-subclassable.&nbsp;</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>.&nbsp;</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. &nbsp; &nbsp; &nbsp;</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=""> &nbsp; &nbsp;* 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.&nbsp;</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span class=""> &nbsp; &nbsp;* 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.&nbsp;</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=""> &nbsp; &nbsp;<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>