[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa]

I'll also stick with "open" for both class and methods and I believe
they should be required for both too. Just as I may not design a class
to be subclassable outside my library, I may not want to allow a
method to be overriden outside the library either (but I may want to
override it inside the library). It also produces a consistent
behaviour (sealed by default): if I have to mark a public class
subclassable, why allow every method in this class to be overridable
by default? If not, there would indeed be necessary the introduction
of the "sealed" keyword to ensure we could close overrides on those
public methods.

I'm also not a fan of "public(open)" because that is how the language
seems poluted to me ("public private(set)" anyone? how is that clean?)
and I tend to avoid those at all cost.

L

On 15 July 2016 at 07:46, Haravikk via swift-evolution
<swift-evolution at swift.org> wrote:
>
> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> To sum this all up, the core team is rejecting this proposal and requesting
> a revision to change the concrete syntax to “public open class Foo” instead
> of “subclassable class Foo".
>
>
> Minor point, but if we're going with the idea of public open and public
> final for declaration, is it worth re-raising the idea of bracketed
> accessibility modifiers? When fileprivate vs private was being discussed I
> was heavily in favour of private(file), private(scope) and private(module)
> (plus private(type) if we get that) to avoid polluting the language with
> more accessibility-specific keywords. This seems like a good time to mention
> it again, as we're now looking at even more keyword pollution:
>
> public(open)
> public(sealed) // Probably not actually defined, but the default for a plain
> "public" declaration
> public(final)
> private(module) // Replaces internal
> private(file)
> private(scope) // Default for plain private
>
> If we get a private(type) that's seven different keyword combinations for
> one feature, so I still very much prefer it being reduced to just
> public/private plus a modifier ;)
>
> This approach satisfies the *unwavering* goal of requiring additional
> thought when publishing a class as public API, makes subclass-ability
> orthogonal to access control, and (admittedly as a bit of a swift-evolution
> process hack) 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?
>
>
> Personally I'm fine with the proposal's original intent; public open gives a
> clear guarantee that overriding is okay, while plain public produces a
> warning encouraging developers to contact an API author if they choose to
> sub-class it anyway, as it may be unsafe. This lets them leave things
> nominally open, and address only the parts of their API that people actually
> want to sub-class, after all, predicting every possible use-case is a
> non-trivial challenge, and I think it's unreasonable to expect it of
> everyone.
>
> That said, linters should probably highlight public declarations that lack
> open or final; if Xcode had a less obtrusive, purely informational,
> "problem" type then I'd recommend that but that's a separate issue I think.
>
> But yeah, I think it's important to avoid trying to force public open or
> public final only, as that could lead to bad habits with developers just
> defining whichever they feel is easiest, probably leading to loads of types
> that end up being final by default. Better IMO to let developers to define
> things the easy way first, then go back and decide what exactly needs to be
> sub-classable once any implementation issues have been resolved.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>