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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
