> • 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
