[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[James Froggatt]

>    * What is your evaluation of the proposal?

I'm not entirely decided, but I think Option 2 is marginally better:
• As long as every member is closed by default, there is benefit to other modules being able to add storage through subclassing, which may never be matched by extensions.
• Knowing every subclass at compile time is possible no matter the default, although I understand the default could influence the direction of the language.

I would guess that most users of ‘final’ use it to ensure the behaviour of every instance of a class is consistent (rather than for the compile-time knowledge that there are no subclasses, or for the small performance gain). This only requires making every member final, something currently not possible to enforce automatically, but would be much easier to enforce for new classes with this proposal.

Option 1 finalises all members by default, but conflates it with the ability to subclass in general, preventing additive subclasses. Option 2 finalises all members by default, but makes an exception for inherited members.

Both options make preserving the openness of inherited members the default for open classes, which in my opinion is dangerous, since subclasses may make assumptions about their behaviour that the superclass did not. If preserving openness of inherited members is to be standard, we at least need a way to opt-out, something like ‘final(members)’, to still allow for additive subclassing. I'd prefer an opt-in solution.

In terms of practical benefit, Option 1 offers very little over Option 2 by making classes closed by default, since overrideability of members is opt-in. Most libraries I've tried make their own class heirachies from scratch.

>    * Is the problem being addressed significant enough to warrant a change to Swift?

I've never had any problem with the current system, and this does risk adding a lot of complexity for only a minor gain in safety, but I support the idea in principle.

>    * Does this proposal fit well with the feel and direction of Swift?

Having open be an alternative to public seems better than the previous revisions. Beyond that, it's hard to say.

>    * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Most languages I've tried use an equivalent of final. This seems complicated in comparison, even with the revisions.

>    * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading through the proposal.