[swift-evolution] SE-0025: Scoped Access Level, next steps

[Joanna Carter]

> I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control.  I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing “internal”.
> 
> Thoughts?

+1

Following on from my experience with Delphi adding "strict private" for "OO private" members of classes, I would totally agree with your proposition.

Having to use Delphi's "strict private" never really felt right to those of us who were brought up on the OO concept of private, and having "private" mean file scope simply encouraged very bad, large, files with lots of classes; especially for those who were new to programming.

This proposal means that folks coming from other OO languages will instantly understand "private"; "fileprivate" does what it says on the tin.

To my mind, the only extra scope that might be useful is the OO concept of "protected" on a class, but I would like to see a discussion purely centred on the effect of more protocols and less class inheritance, with its attendant impact on whether protected could also suit extending (otherwise private) scope to extensions.

In recent experiments of adapting the GOF Design Patterns to Swift, I have found using protocols and extensions to greatly reduce the need for class inheritance, if not removing the need for classes at all in favour of structs.

Joanna

--
Joanna Carter
Carter Consulting