[swift-evolution] Final by default for classes and methods
rodney.brown6 at icloud.com
Tue Dec 22 16:48:54 CST 2015
> On 23 Dec 2015, at 7:20 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> You're quite right, but imho the whole issue is bigger than a few characters that have to be typed to get the desired inheritance characteristic: That would not drive discussion that long.
> It's also about the philosophy that backs the choice, it is freedom vs. safety, and any default value is a statement in favor of one of the extreme positions — and it is a little push for anyone designing a library, including those who work at Apple.
> The idea of encouraging an explicit choice has value; I think a proposal to have no default at all wouldn't have created such a big debate...
And that is ultimately the crux of this issue, isn’t it?
If Swift defaults to finality or “sealed", this could end up with every framework allowing very minimal subclassing just by a matter of culture, which I think we all agree with frameworks like UIKit showing where this is really probably not what we want.
If Swift defaults to open, then we have more compatibility problems if a class is, further down the road, final or sealed, and the performance benefits of Swift would be marginal at best.
I think at this stage, we have to begrudgingly accept that external subclassing will be disabled by default. The problems with open-by-default are simply too many and varied, as has been discussed at length here. Framework vendors will probably close their own classes manually anyway if it’s not there.
Whether closing the classes takes place as “sealed” or “final” is a matter for more debate. Personally I support Sealed, but I wonder whether that has implications for compiler optimisations when it cannot assume that “sealed means final” because a framework could potentially vend me a private subclass of the sealed class.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution