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@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@swift.org> wrote: > > > 2016/07/16 21:37、Jean-Daniel Dupas <mail...@xenonium.com> のメール: > > Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution < > swift-evolution@swift.org> a écrit : > > 2016/07/15 16:37、Riley Testut via swift-evolution < > swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution