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

[Shawn Erickson]

Yeah I am fairly sure at this point in time "open" is purely about a
statement of API contract (defaulted such to favor being explicit) which
IMHO is a very good tool to have in the toolbox for module/framework
developers. If it proves out to work well then I believe compiler
optimizations could start to leverage it but I don't think any of those are
in place currently. By that same token if "monkey" patch is seen to be
important that could be proposed in the future as well. (on the later the
core team – and myself included (not a core member) – don't favor the
monkey patching view of things, especially in the face of all of the other
Swift things aren't sub-classible).

-Shawn

On Mon, Aug 15, 2016 at 9:09 AM Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

> Yeah I know - that's why I said it would only work if we are okay with
> saying non-open != final, as a long-term decision. So the compiler won't
> devirtualize those calls.
>
> As I understand it, that is how it works today - calls to non-open,
> non-final classes are still dynamically dispatched. There was a suggestion
> to make non-open == final, but that was expressly rejected.
>
> Karl
>
> Sent from my new Email
> <https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email>
>
>
> On Aug 15, 2016 at 9:50 am, <Jean-Daniel Dupas <mailing at xenonium.com>>
> wrote:
>
>
> > Le 14 août 2016 à 20:43, Karl via swift-evolution <swift-evolution at swift.org> a écrit :
> >
> >
> >> 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.
> >
>
> The non subclassable across module boundary is not just a compiler enforced limitation. Once you compile a module with classes that are ‘final’ in the module, the compiler may devirtualize all call sites in the module, or even inlining some calls, making subclassing unpredictable and pointless.
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/66f7f257/attachment.html>