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

[Charlie Monroe]

> On Jul 7, 2016, at 1:10 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In the motivation section performance 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. 

There kind of was a discussion on this.

John McCall (http://article.gmane.org/gmane.comp.lang.swift.evolution/22111 <http://article.gmane.org/gmane.comp.lang.swift.evolution/22111>)

> 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.


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...



> 
> 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. "public sealed class Foo"  and then for the methods / properties that are clear extension points should be flagged overridable.  I would prefer something like that. And I think it would be more intuitive. 
> 
> 
>>    * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> No. 
> 
>>    * Does this proposal fit well with the feel and direction of Swift?
> 
> I think it is counter-intuitive. I don't think that reading "public class Foo" would make anyone think that Foo is non-subclassable. 
> 
> On the other hand, reading "public class sealed Foo" would suggest to the reader that the class can be overridden but only the methods that are flagged as overridable. 
> 
> If we wanted to prohibit overriding then we could use "public final class Foo" 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.      
> 
> 
>>    * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I don't recall having seen this behavior in the languages that I have worked with. 
> 
>>    * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> I read the whole proposal and have been thinking about the implications for a few hours. 
> 
>> More information about the Swift evolution process is available at
>> 
>>    https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> _______________________________________________
>> swift-evolution-announce mailing list
>> swift-evolution-announce at swift.org <mailto:swift-evolution-announce at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce <https://lists.swift.org/mailman/listinfo/swift-evolution-announce>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/424039ea/attachment.html>