[swift-evolution] [Proposal] Sealed classes by default

[Karl]

> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi folks,
> 
> I see from building the latest Swift-3.0 branch that I’m a little behind the times and this proposal has been accepted :(
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Is there no way we can revisit this decision? 60 emails on a mail group not read by the whole community
> doesn’t quite seem enough validation for such a significant change to me. Of those that expressed an
> opinion on the thread many were against sealing classes outside the module. 
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html
> 
> I personally feel it's a huge mistake for the following reasons:
> 
> 1) it “breaks open source” reducing the reusability of third party software by default.
> 
> 2) Contrary to arguments about the likely performance benefits of de-virtualisation of method dispatch it is
> likely to make Swift programs launch more slowly due to the dynamic linker having to slide large numbers
> of function pointers for most method calls (itself an expensive operation) whether a call is even made.
> 
> On the first point it's an established technique in OOP to be able to subclass and override to adapt a class
> for a role perhaps it’s author never considered. Call this “monkey-patching” if you like but it is a part of being
> able to use open source libraries without having to make a fork as would be the case if sealed by default.
> Are we expecting developers to remember to leave their classes (and methods?) "open”? If they do feel
> that others shouldn’t subclass or override there was always “final". Distinctions about whether this is possible
> inside or outside a module seem a mute point to me.
> 
> The second point is more of an engineering one. “Virtual” dispatch on Swift is not a significant overhead
> compared to fully dynamic dispatch on Objective-C which even then was seldom a problem. There is a
> cost however to de-virtualisation and resolving to a direct call to a method address in that the dynamic
> linker has to resolve and slide the pointer on load. This type of concern is a bad argument to use in 
> designing a language anyway even if it is called Swift.
> 
> Well, I know the boat has left on this one and I’ll likely have to live with it but this is the proposal I
> most disagree with on evolution this far. Programmers have morals and just because you shouldn’t
> do something doesn’t mean the language needs to turn that into can’t by default when the need arises.
> If this change does go ahead please try to get it into the next Xcode beta as it is a very incompatible one.
> 
> Cheers,
> 
> John
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

It we are happy with non-open != final, I would be in favour of some kind of monkey-patching import attribute, similar to @testable, which allows you to subclass non-open classes at your own risk.

I would be doubly-happy if we were to call it "@monkey-patched import UIKit"

Karl