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

[Tony Allevato]

On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner <clattner at apple.com> wrote:

> Hello Swift community,
>
> The review of "SE-0117: Default classes to be non-subclassable publicly"
> begins now and runs through July 11. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
>         * What is your evaluation of the proposal?
>

+1. As a big proponent of API reviews for code that's going to end up being
used by others, I think sealed-by-default forces authors to think about how
their code might end up being used by others more so than more-permissive
alternatives. Seeing a keyword that marks a class as unsealed is a good
opportunity to start a conversation in a code review.

Given that Swift tries to encourage the use of value types over reference
types in many places, which can't be subclassed anyway, I don't think this
change should be a significant burden. I'm in the process of implementing a
fairly large library that's about 95% value types and 5% reference types.
The reference types are more of an implementation detail than a hierarchy
of types, so I would have them be final anyway. This is completely
anecdotal, of course, but it's a testament IMO to how differently Swift has
me thinking about the way I structure my APIs, and subclassing has been
mostly replaced by protocol extensions and composition.

I'm not compelled by the arguments that we need subclassing to fix bad
APIs, because that's absolutely not what subclassing is intended for. It's
a hack, and it's not a cure-all—it relies on being able to override the
correct methods and inject custom behavior in the first place. The argument
shouldn't be "we need open subclassing or we can't fix broken APIs"; that's
a false choice. It should be "we need *something* to fix broken APIs", and
that "something" should be proposed and the need for it should be argued in
its own right. The ability to fix a sealed broken API does have value, but
it is inherently unsafe because you might be making assumptions about
pre/post-conditions that the original class author didn't think about, and
those assumptions could become invalid in the future (or might rely on
internal implementation details that you cannot predict). Rather than
abusing a construct that is not suited for that purpose, those arguing for
the need for that functionality should propose something more appropriate.
This would be a win-win; we'd have a clean way of expressing API
boundaries, and an unsafe-but-acknowledged-as-such way of hooking into APIs
if a trap door is needed. (Of course, with Swift at such a young age, it's
hard to know what the needs for that are until we have some more mature
libraries to present as use cases.)



>         * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes.



>         * Does this proposal fit well with the feel and direction of Swift?
>

Yes. The behavior that classes are unsealed within the same module but
sealed by default outside the module aligns nicely with the way internal
visibility already works in the language. Newcomers and app developers
don't have to think about it, but those who want to release code for others
to use must; I think that's the right level of responsibility.



>         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

        * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

Read the proposal and followed the heated discussion in the review thread.



>
> More information about the Swift evolution process is available at
>
>         https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/071bae94/attachment.html>