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

[Matthew Johnson]

> On Dec 23, 2015, at 12:26 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
> Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> 3) Annoyance.  Some consider it to be annoying to have to annotate a class declaration in order to inherit from it.  People stating this argument either are either writing a lot of superclasses or are so bothered by the need to annotate their type declarations that they avoid `final` and its related benefits when that is really the right thing for their class.  For me personally, `final` is the right thing for most classes I write.  I also think adding a `final` annotation is the right thing to do if you’re not sure whether it will be a superclass or not.  The need to modify the annotation will remind you that you haven’t fully considered inheritance in your design yet.
>> 
>> ...
>> 
>> 5) Prototyping.  This should also not influence the decision about what the default is for production code.  I would not have a problem with a prototyping environment allowing `inheritable` by default (maybe a Playground mode?).  There could even be a tool that migrates the prototype to a real project and adds the `inheritable` annotation where necessary.  Regardless of what happens here, the prototyping problem can and should be solved independently of the production language and should not influence the default is used in and impacts production code.
>> 
>> 6) Education.  There may be some value in allowing inheritance by default in education settings, especially early on.  I view this as being quite similar to the prototyping case and again should not have an influence on the default that professionals use in production code.
> 
> I think these three concerns would be addressed in good part by having sealed by default instead of `final`.
> 
> I'm not sure why you say the last two should be addressed separately from the "production" language. Are you proposing Swift should come in multiple language variants?
> 

Not exactly. 

My point is that it is best to design the language to address production concerns first.  If the defaults in that design cause problems for prototyping and / or education it is possible to offer an environment with a modified default.  I don’t know if that is a good idea or not.  I am not a target user for either of those use cases (personally, I would rather prototype with the production language).  Either way, it is possible, just as it is possible to have @testable to facilitate unit testing.

I strongly feel that I shouldn’t pay a price in production code in order to better support those use cases.  IMO ‘final’ is the right default for production code and we pay a price if the default is anything less, including ‘sealed’. 

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/e1ac41fd/attachment.html>