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

[Riley Testut]

Fully agree with Kevin here. I would really hate to see final as the default for classes/methods. In addition to subclassing just to add custom behavior, everyone writes bugs, and sometimes (unfortunately) the clients of an API have no choice to fix the bugs besides subclassing and fixing them themselves. Additionally, it would be significantly harder (IMO) for newcomers to grasp the concept when subclassing is limited to certain classes but not others. If you actually need that performance gain, you can easily add the final yourself.

It is true that “it is not uncommon to have a need for a reference type without a need for inheritance”. However, that does not mean this should be the default, IMO. So while I agree in theory it would be nice, in practice I don’t want to prevent potential clients of Swift APIs from accomplishing their goals in the easiest way possible.

> On Dec 7, 2015, at 11:30 AM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/c15ffe8d/attachment.html>