> On 14 Jul 2016, at 22:39, Chris Lattner via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
