[swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Paul Cantrell]

> • What is your evaluation of the proposal?

Breaking it down in parts:

+1 to the basic principle of making the external subclassing a conscious, explicit API design decision.

+1 to providing a design state for subclassability that leaves the most room for non-breaking future changes. Those who think about API design know that allowing subclassing is a non-retractable promise, but the fact that “final” will _also_ be non-retractible in Swift when we have ABI stability is a slam-dunk argument for the existence of “open.”

+1 to the word “open.” I went back and forth on this a little, pondering “subclassable,” “overridable,” etc., but those terms are misleading: they imply “not final,” and don’t capture the fact that module boundaries are an important ingredient of the concept at hand here.

-1 to “open” implying “public.” I continue to feel that I want to see the word “public” on every element that is part of my public API. I don’t mind “public open,” and the rationale in the Alternatives section didn’t sway me. However, I don’t consider this point a dealbreaker, and am still in favor of this proposal overall.

Without having a very strong feeling about it, I’m in favor of the “first design,” i.e. the existence of non-open, non-final classes. It’s the less surprising model, somehow. I also like the idea of a library being able to make assumptions about a closed set of subtypes, just as enums allow assumptions about a closed set of values. (A future construct could even apply enum-like code path analysis when switching on a supertype with a known set of subtypes.)

Despite that, I would accept the second design (no such thing as “open class”) if it consensus favored it.

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

Yes. It would be on good API design principles alone, but the coming ABI stability problems around final, at least in my dim understanding of them, makes this crucial.

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

It does.

Swift favors making consequential design decisions explicit, and “non-final by default” currently breaks with that principle.

“Subclassable within a module by default” is consistent with Swift’s “internal by default” attitude.

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

Other languages have solved these same API design concerns with “final by default.” I prefer this alternative.

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

I’ve loosely followed the conversation from the beginning, though I confess I did not count every sling and arrow in the long message threads.

Cheers,

Paul