The keyword `open` would only be required to allow subclassing **outside** of the module. You will still be able to subclass inside the module as long as it isn’t marked as `final`.
This proposal wants classes to be `final`-by-default **outside** of the module and subclassable by default inside the module. This is about making sure developers don’t accidentally release an API promising a more than they’re able to support. Once they decide that (a) a class won’t break when subclassed and (b) they’d like to support subclassing for that class until the next breaking change, they annotate the class with `open`. > On Jul 19, 2016, at 9:42 PM, T.J. Usiyan via swift-evolution > <[email protected]> wrote: > > I am ok with moving the public requirement for sealed-by-default. I have one > qualm though. This would actually make starting out with the language a > suboptimal experience. As (before, really) I teach what subclassing is, I > have to explain this keyword to make subclassing possible. That sounds good > until I realize that I should explain when you would want to add this keyword > and I still haven't even gotten into what subclassing is yet. > > On Tue, Jul 19, 2016 at 9:14 PM, Karl via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On 17 Jul 2016, at 23:37, Brent Royal-Gordon <[email protected] > > <mailto:[email protected]>> wrote: > > > >> On Jul 17, 2016, at 7:29 AM, Karl Wagner <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Open and public are orthogonal concepts, just like final and public are > >> today. > > > > Are they? Given that "open" *means* "subclassable/overridable in public > > scope", what would it mean for something to be open, but not public? > > `final` *is* orthogonal, but I'm not sure `open` is. > > > > -- > > Brent Royal-Gordon > > Architechies > > > > > Well that’s the point - we disagree on what “open” means. I don’t agree that > the “in public scope” qualifier is necessary. > > Why are we doing this at all? Because we recognise that writing good base > classes is hard. > Why is writing good base classes hard? Because it’s difficult to locally > reason about your code when members may be substituted by third parties. > > So what does this solution do? It explicitly annotates those members which > may be substituted. > > This is a general problem - it doesn’t just affect publicly-accessible base > classes, but also internal ones. It’s okay to be a bit sloppy with > only-internally-open classes because you completely control every > substitution, so you can fix any bugs later with an isolated library update. > That is the only reason anybody could have for limiting “open” to public > scope, as far as I’ve been able to tell — because it makes it easier to be > sloppier. > > Still, I believe it would not do us any harm, and would actually do quite a > bit of good (in light of the Swift API Design guidelines, which promote code > which is easy to locally-reason about) if we applied this reasoning to all > access scopes. > > That is to say, we basically introduce “open" as an inverted “final”, and > make all classes non-open by default. That is analogous to enabling > whole-module-optimisation by default, in my opinion. The cost of an extra > four-letter word isn’t that great, but the benefits to readability and > reasonability all-around make it worthwhile. > > Karl > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
