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

[Tino Heth]

> 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?

Despite of probably being one of the most passionate defenders against adding restrictions on subclassing, I've to accept the clear statement made by the core team, so the imho only consequent answer to this question is requiring overridable on every single method:
- Whatever the perceived benefits of forbidding subclassing are, they are the same for each specific method
- It is the same principle that is applied to access control

For me, "open" has a tiny disadvantage, because I tend to read it as a verb, but it's most likely the best choice, and I recommend to re-use it and drop overridable:
- open is shorter
- open is less confusing
- access control follows the same principle of reuse

If the goal is taken serious, imho it is also questionable wether it is good to allow writing public properties without explicit rights to do so: It's a similar situation (you can read but not write vs. you can call but not override), and there is the proven template of default file access rights in UNIX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/39945e41/attachment.html>