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

[John McCall]

> On Jun 28, 2016, at 8:09 AM, Javier Soto via swift-evolution <swift-evolution at swift.org> wrote:
> 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. 

Also, note that:
  - we're clearly going to have to import ObjC classes as subclassable by default, and in fact there's currently no way to explicitly declare an ObjC class to be final;
  - many classes in ObjC are actually intended to be subclassed (although not every method is intended to be overridden), and those tend to be the classes that users most want to patch;
  - methods in ObjC can just be directly monkey-patched without subclassing, even if we're not necessarily happy about you doing it; and
  - even if we re-implemented a bunch of frameworks in Swift, we'd still have to maintain compatibility with some amount of this stuff.

So I don't think that sealed-by-default would have any significant impact on the ability to patch Apple code as a third party.

For code that isn't deployed in an OS that won't be updated, the obviously better solution is to fix the library, either yourself or, if it's closed-source, through your normal vendor support process.

John.

> On Tue, Jun 28, 2016 at 7:59 AM Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >>>
> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> -- 
> Javier Soto
> _______________________________________________
> 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/20160628/2dac071d/attachment.html>