[swift-evolution] Final by default for classes and methods

[David Owens II]

The problem is that this perpetuates the fundamental problem with type hierarchies: the further down the rabbit hole you go, the more fragile your types end up being. 

I’d much rather design for inheritance rather than having it be opt-in by-default. I really like the inheritable only from within the module by default idea that Joe and Slava mentioned.

> On Dec 7, 2015, at 11:21 AM, Kevin Lundberg via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Resending to whole list:
> 
> I can appreciate the desire for this, but I would not support it personally. In a former life developing C# code where this is the default behavior, I wanted to extend a class's behavior to make it work slightly differently, but since everything is final by default (sealed in C# parlance) I was prevented from doing so. The scope of my change was minimal and well defined, and it would not have negatively impacted the extending class's normal behavior. The code I was extending was open source so i ended up having to copy and paste the class and its dependencies into my project to do what I wanted. If I couldn't have done that then I'm not sure what the right approach would have been. 
> 
> In short, it is not always possible to know ahead of time how your clients will want to extend your API's functionality; artificially limiting this in my opinion will make it much harder to reuse components in previously unforeseen ways.
> 
> --
> Kevin Lundberg
> 
> On Dec 7, 2015, at 2:12 PM, Javier Soto via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> This was brought up in a different thread about private by default. Creating a new thread for this. Quoting Mathew from the other thread with a short summary about the motivation behind this:
>> 
>> "It is not uncommon to have a need for a reference type without a need for inheritance.  Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design."
>> -- 
>> Javier Soto 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> 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/20151207/0b442e71/attachment-0001.html>