Dear Swift community and core team, please don’t judge me too much or scream at me just because I want to talk about this particular topic with you. I hope we can have a nice, constructive and democratic conversation here. I’m not a compile engineer, so my words can be wrong or wrongly interpreted since I’m not eloquent nor am I a native English speaker.
The current status quo of the access control below
public is that we wanted to find a better default for
private last year to fade out
fileprivate, by making
private a little bit more like
fileprivate but limiting it to the type. The Swift community - from my point of view - is sliced in two halfs. One half moves a lot of type related computation and type internal API into extensions and different files, the other half may not care about such code organizations and stack everything into one giant file. For some reason the access control seems to prioritize the second half and is still completely inflexible for the first half of Swift developers. If you take a deep breath and think for a second then you may start to realize that
fileprivate has lost it’s weight, at least from the naming perspective.
fileprivate really is not an access modifier that allows access to private type members but an access modifier that grants visibility to the type member only in the current file. If we put that with different words then it becomes a file internal access modifier.
I speak here for myself, and only for myself, but I think that probably everyone from the mentioned first half wished to gain access inside a type extension, inside the same module to the private members. But for some reasons this access level does not exist in Swift, therefore it feels like the current access control does prioritize only the second half of the Swift developers that do not organize their code in different files. You may argue that we can document members that require this access control to warn our colleagues from using it, but this does not solve the issue nor does it prevent it. I think it’s fair to say that access control was invented for a specific reason, not one that should rely on documentations.
To sum up the issue below public access control:
- Last year we tried hard to find a better default for
privateto fade away
fileprivate, which kinda worked.
- The new default limits the access to the current file and keeps it private to the type (in fact, it became the true
fileprivatestats to fade away but has completely lost it’s weight from the naming perspective.
- [I think] We can migrate the access control in a rotational manner to find an ever better and far more flexible default for
- [I think] We should deprecate
I’m not directly proposing this change but would love do discuss it here and see where it goes.
fileprivateand introduce a new kind on how to express an access modifier by prefixing a specific set of exiting access modifiers with parentheses with a special keyword in-between:
(file)private(this is necessary for safety migration to prevent possible collisions with the new default for
Introduce the new default
privatewhich would allow to access that particular type member from inside any file inside an extension of the same type where that member was declared. As mentioned before to prevent possible collisions we would need to migrate current
(file)privateand then everyone can manually remove
(file)where no collisions are possible or resolve the collision before removing
(file)prefix from before
Another argument against this is to introduce sub-modules and let them handle the mentioned access control issue, but this only forces you to create dozens of small sub-modules to compensate the main issue by lifting the access control one level up which will resolve to even more boilerplate code.
I might have forgot to write something while I tired to describe the issue in an understandable way from a non-compiler engineer who’s lacking some compiler jargon.