> On Jul 14, 2016, at 4:39 PM, Chris Lattner <[email protected]> wrote: > > To sum this all up, the core team is … requesting a revision to change the > concrete syntax to “public open class Foo” instead of “subclassable class > Foo”.
Yes, +1 to “public open Foo” instead of “subclassable Foo”. Presumably “open” without “public” is an error…? > [The core team] asks the community for an in-depth discussion of the > secondary points of the proposal: does it make sense to require every member > to be marked as “overridable” in order to be overridden by an open subclass > outside of the current module? Tentative +1 to this, though I’m open to hearing arguments otherwise. One could make a good case for overridable being the sensible default and require an explicit “final,” just as for internal subclassing. I lean against this for two reasons: Explicit “overridable” is consistent with the general principle of explicit exposure of public promises in public APIs. When a class is declared public, its members are still internal by default. By analogy, class-level “open” shouldn’t make members overridable by default either. With a language like Swift that encourages developers to lean on the compiler for verification, setting consistent expectations is crucial, and this behavior seems more consistent to me. I look at this proposal primarily from the point of view of a library author who is trying to design their API right, and is looking for assistance from the language in achieving that goal. The core team’s proposals seem consistent with this. This makes me wonder whether we should remove member-level “final” from the language, and require “overridable” (i.e. final methods by default) even for members of non-open classes just for consistency and simplicity. That may be a separate proposal, but does seem like it needs consideration for Swift 3. Cheers, Paul
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
