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

[Karl]

> On 21 Jul 2016, at 20:49, Chris Lattner <clattner at apple.com> wrote:
> 
> On Jul 21, 2016, at 8:56 AM, Karl <razielim at gmail.com> wrote:
>> 
>> Just posted in the Review #2 thread. I read the updated proposal, and I have another idea besides making “final” default:
> 
> Hi Karl,
> 
> Please respond to proposal on this thread with your evaluation of it.  This isn’t the right place to make counterproposals.
> 
> -Chris

-1 from me. Same reasons as before, I think:

First proposal:
- Conflation of ‘public’ and ‘open’; it feels like open is a new higher access level, like getting married, or going sudo or something. If this proposal was accepted, ‘open' should substitute ‘public’, and never be alongside it (the same way “public private class” makes no sense)

- The concept of classes/class members which are closed until ‘open’ed is a powerful one for documenting classes and writing locally-reasonable code. It shouldn’t be mixed up with exposure to external modules - we already have a concept to describe that; it’s called access levels and ‘public’. I’ve worked with horrible base-classes before with a mixture of internally overridden and non-overriden members, and I would have absolutely loved some compiler-enforced annotation in that case. It makes sure that people stick to the contracts for a class’ members, and that breaking them is something you need to think twice about.

Second proposal:
- I’m arguing for increased local reasoning for classes, this proposal wants to make more of the permissions implicit. I’m not a fan.
- Extra API can be added with extensions. Extra state is something we should look in to in general. Obj-C had associated objects; maybe we can do better with Swift.

Basically, if you consider that we would need an explicit keyword for the default, non-open state (lets say “sealed”) as we have for “internal” - whether or not it applies inside the module is the only difference between the first proposal and my counter-proposal.
We could make that change later, but I think we should go with the sound logic behind this idea, and go with the expectation of safety and local reasonability, and try to make it as consistent as possible from the start. We could loosen it up to only apply to ‘public’ members if too onerous (although my preference would be shorthands - “open-all” or something).

Karl