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

[T.J. Usiyan]

What happens if I want an `internal` subclass of an `open` class?

On Sat, Jul 16, 2016 at 10:09 AM, David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> Swift has always gone towards making declarations explicit to read. Having
> open on thé class declaration makes it so you don't have to go hunting into
> its members to see if it contains an open member.
>
> Other comments inline:
>
> On 16 Jul 2016, at 14:49, Andre via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 2016/07/16 21:37、Jean-Daniel Dupas <mailing at xenonium.com> のメール：
>
> Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> 2016/07/15 16:37、Riley Testut via swift-evolution <
> swift-evolution at swift.org> のメッセージ:
>
> FWIW, I'm still against this proposal, but since it will be accepted
> regardless, here are my thoughts:
>
> • Open keyword is significantly better.
> • Members should be *open* by default, and final should be opt-in. If
> you're opening up a class for subclassing, my gut says you should allow the
> client to do as they wish.
>
> If you have a class that was not open yet, just making it open wouldn't
> expose any members: it would then just be subclassable.
>
> If the act of making the class open doesn't implicitly make overriding
> possible, well all you can do then is add methods, and that can be done
> with extensions anyways, so it's not as useful and makes the *public open
> class {}* pattern *just* by itself not so useful imho... 😬
>
> Also, the keyword 'open' itself may imply 'hey I'm open, please do what
> you want with my public members', whereas 'subclassable' is more specific
> in intention...  (but that's just me, so n=1 and all that)
>
> TLDR; +1 to the above: simpler is better and defaulting to overridable for
> public members on an open class is simpler... invariants can be protected
> by the 'final' keyword.
>
> If we were to default to non-overridable, a more consistent 'open' on the
> method is preferred over overridable for me... open class, open method...
> much better imho...
>
>
> Do we really need an open keyword ?
>
> As already said, if open does nothing more than allowing the class to be
> subclassed, why not simply make the class subclassable if it contains at
> least one overridable member ?
>
> Thats a good point actually… but looks like Review #2 has already started…
> and 'open' is available for both class and method there… I suppose its the
> whole "default to safe", just in case someone made one method 'open' they
> may not have intended to actually make the whole class open… (also see
> below)
>
> In case we require an open keyword, what would happen if someone mark a
> member overridable, but does not make the class open ? Will the compiler
> emit an error, or make the class implicitly « open » ?
>
> In proposal #2 looks like it would generate an error, but Xiaodi Wu has
> said that it should be allowed and not generate an error per SE-0025
> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
> .
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types>Take
> a look at
> <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types>:
> "The compiler should not warn when a broader level of access control is
> used within a type with more restrictive access, such as internal within
> a private type."
>
>
> I'm fairly sure that does not apply to open as it's fairly orthogonal to
> other access control modifiers.
>
> - Andre
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/f562ebf1/attachment.html>