Just to clarify Karl, with your idea here, final wouldn't be necessary right? Since everything is already final by default? On Tue, Jul 19, 2016 at 6:15 PM Karl via swift-evolution < [email protected]> wrote:
> > > On 17 Jul 2016, at 23:37, Brent Royal-Gordon <[email protected]> > wrote: > > > >> On Jul 17, 2016, at 7:29 AM, Karl Wagner <[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] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
