> On 23 Dec 2015, at 7:20 AM, Tino Heth via swift-evolution
> <swift-evolution@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.
-Rod
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
