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

[Tino Heth]

I'm not sure wether the review period is actually over (or better say "turned into an internal discussion", as I haven't seen a result yet ;-), but as nobody jumped onto the "something more holistic"-train, I used my free time at the lake for some thinking…

There are three degrees of freedom, which makes it hard to create a complete table, but in essence, we are talking about this matrix:

Subclassing allowed	Subclassing forbidden
Instantiation allowed	open (public)	final (public final)
Instantiation forbidden	abstract	internal

As we have two* choices for each aspect, we have four keywords — no matter if we give each combination its own name, or build combinations of them.
I think combinations are less appealing, because there are already established terms for all cells, but your milage may vary.
Swift currently has no clean separation of the concepts, so "final" is actually "public final".
The matrix contains "abstract", and if you put the preoccupation of "everything should be done with protocols!" away, I guess you'll recognize the beauty of symmetry which is disturbed because one modifier is missing (I guess no one argues that we need something like abstract — it is just about how it can be expressed).

This simple table could be everything that is needed… if Swift had only a separation between modules (and as it has been decided to increase the number of levels, that simplification doesn't seem realistic).

So, we have an impressive number of four access levels, and it starts getting complicated to deal with 16 different keywords… but there is already a well-known alternative to model access rights based on the status of the accessor:
File rights in UNIX.
This system can be operated in a way that I wouldn't recommend for a programming language ("func 755 foo()" anyone?), but also in a more explicit form ("group=rwx"…).
The second variant could be adopted for Swift, and that is where it's getting really complicated, because syntax like "module=subclass, public+call func foo()" most likely isn't "swifty" as well… 

None the less, this model would bring true orthogonality, and establish a clean separation of concerns.

- Tino

* properties left aside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160727/645285ad/attachment.html>