[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Peter Livesey pdlivesey at gmail.com
Tue Jul 19 22:48:35 CDT 2016

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 <
swift-evolution at swift.org> wrote:

> > On 17 Jul 2016, at 23:37, Brent Royal-Gordon <brent at architechies.com>
> wrote:
> >
> >> On Jul 17, 2016, at 7:29 AM, Karl Wagner <razielim at 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 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/20160720/620a86c3/attachment.html>

More information about the swift-evolution mailing list