> Le 21 févr. 2017 à 02:25, Derrick Ho <wh1pch...@gmail.com> a écrit : > > I've thought about how to deal with override in a way that is consistent with > the language. Maybe something like this? > > // publicly visible but can't be subclassed. > public private(subclass) > > // publicly visible and may be subclasses within the module. The default > public internal(subclass) > > // publicly visible and may be subclasses by all. > public public(subclass) > > We also can not forget how it apples to methods > > public private(override) > public internal(override) > public public(override)
The main problem I see with such naming is that, by the use of the word 'subclass', it implies this is about dealing only with classes. The reality of the Swift world is that it is no longer just classes that are extensible (by subclassing) but, also, extensions that can be written against any type. Personally, I still balk at the idea of bracketed visibility specifiers. -- Joanna Carter Carter Consulting _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
