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

[Javier Soto]

IMO the issue with the argument that we wouldn't be able to "monkey patch"
things on sealed classes is that that is already the nature of Swift. The
designer of an API can choose to use structs instead of classes, and then
there's already no way to "subclass". Moreover, "final" already exists, and
whether sealed is introduced or not, and whether it becomes the default or
not, API designers are already free to use final in all classes they do not
intend to be subclassed, so I think that would be an argument against final
existing in the first place, and that ship has already sailed.

As for whether sealed would allow for optimizations: my hunch is that it
would. However, as I write this I noticed a flaw with my proposal: I said
that sealed classes would be exported as final. This is only half-true.
They would in that they can't be subclassed outside the module, but there
could be subclasses in the same module! That means if the parent were to be
treated as final, code outside the module would incorrectly devirtualize
non-final methods.
On Tue, Jun 28, 2016 at 7:59 AM Charlie Monroe via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>>
> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> -1 for the fact that if all devs can write working code, fewer can do
> it in a clear structured fashion that is well designed for extensibility.
> >>
> >> This sounds more like an argument for having sealed classes than not.
> As the proposal points out in the motivation, if the base class is not
> designed with subclassing in mind then overriding methods can result in
> unintended behavior (e.g. crashing, or other bugs).
> >
> > But I think the counter argument is, what if you need to fix or
> workaround unintended behavior of the class you’re trying to use?
>
> Typically you modify something open source - 99% of which is on GitHub.
> IMHO the best way is to either fork it and perhaps submit a pull request
> with the fix.
>
> But I understand that this is not always possible...
>
>
> >
> > l8r
> > Sean
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/e8ea08eb/attachment.html>