Here’s the core of the suggestion:
“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.”
That is, the suggestion is that subclassing classes and overriding methods should be implicitly banned unless the framework author takes specific action to permit such indignities. The idea has evolved a bit over the last two+ weeks, to suggest that this implicit ban only apply across module boundaries.
I was shocked to find many members of the Swift team at Apple agreeing with this suggestion. When I’d mentioned the suggestion to co-workers and to friends in the app development community, to a person they said it was ridiculous. Most made some variation of the argument that I posted to the mailing list:
Anyone who tries to ship products on release day of Apple’s operating system updates spends most of August and September writing horrible hacks so that their users are insulated from OS bugs as much as possible. All software has bugs, frameworks included. Please don’t take away our tools for working around those bugs. Making classes final by default assumes a level of perfection on the part of framework developers that is not achievable.
Yes, subclassing a class that wasn’t designed to be subclassed has serious risks. Thoughtful developers sometimes take on those risks in order to serve their customers.
Frankly, I think having final in the language at all is a mistake. While I agree that we should prefer composition to inheritance*, declaring things final is hubris. The only reasonable use case I’ve seen is for optimization, but that smacks of developers serving the compiler rather than the converse. Bringing an analog of NSREQUIRESSUPER to Swift would be most welcome; that’s as far as I’d go down the path of dictating framework usage.
*- and am thrilled with the property behaviors proposal for this use case