There was an order of magnitude more than 60 emails about this. In my inbox, I count 452 emails that have 0117 in the title. Discussion had already started before the proposal and I'm not counting these.
Félix > Le 14 août 2016 à 02:17:36, John Holdsworth via swift-evolution > <swift-evolution@swift.org> a écrit : > > 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
