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

[Joseph Lord]

On Dec 7, 2015, at 7:19 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> On Dec 7, 2015, at 11:12 AM, Javier Soto via swift-evolution <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."
> 
> There's a refinement of this idea we've discussed internally in the past. Instead of making classes final by default, we could make it so that public classes are not subclassable from other modules by default. Inheritance is manageable within a module, where all of the involved subclasses are revlocked and potentially have access to each other's implementations anyway, and the benefits of `final` and closed class hierarchy analysis are easy to recover with whole module analysis so don't necessarily need explicit calling out for internal interfaces. The problems with inheritance rear their head more with public interfaces, once code outside your control can subclass your classes.
> 
> -Joe

I'm a strong supporter of the original proposal of default final classes (and would add to the arguments the performance gains of final even though the compiler can often finalise things anyway). I'm less sure about the within module special case sub classing behaviour (I'm not opposed but I'm not sure it is worth complicating the language for). 

Most of the scenarios I can imagine could be implemented with an internal delegate property that provides for the specialisation of behaviour. Are there use cases that couldn't be managed in this way? I suppose it might be a cleaner way to modify varying amounts of the functionality by sub classing but I'm still not convinced for general development that it is worth expanding and complicating the language for different in module behaviour or addition sealed concepts.

Joseph
@jl_hfl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/7b258ac9/attachment.html>