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 < swift-evolution@swift.org> wrote: > > > On 17 Jul 2016, at 23:37, Brent Royal-Gordon <br...@architechies.com> > wrote: > > > >> On Jul 17, 2016, at 7:29 AM, Karl Wagner <razie...@gmail.com> 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 > 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
