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

[T.J. Usiyan]

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 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/6f21a3fe/attachment.html>