IIRC the current private was changed from being a scope-private access modifier to a file-type-private access modifier with the vision of a softer default access modifier. That means the usage of the fileprivate should fade, but not be eliminated. The underrated issue of a scoped private was that it forced developers who tend to offload blocks of code into extensions to make more use of fileprivate than they wished to.
The following part of my answer will >>summarize<< my ideas from the linked thread, but is not meant to de-rail the current topic nor is it proposing anything in this thread.
Click to unfold.
I discussed my concerns about the current behavior because it's highly restricted to one camp of access preferences. Furthermore it creates some weird inconsistencies in names.
In this older thread I discussed on how this can be improved by eventually deprecating fileprivate by introducing limits to some access modifier.
| Current | Wish | Comment |
|---|---|---|
| open | - | visible and can subclassed in outer lib (but in my opinion it should be generalised and also mean "can conform to a protocol from inner lib") |
| public | - | visible but cannot be subclassed in outer lib, can conform to a protocol from inner lib (I would wish that it would mean "cannot conform to a protocol from inner lib, but allows interface like usage of it as existential") |
| internal | - | - |
| fileprivate | (file)internal | true access of this modifier is on the same level as internal but restricted to a file |
| private | (file)private | this is a true file private access modifier because it's restricted to the type and the file |
| - | private | new soft default which is only bound to the type but not to a type |
This would leave us with 4 access modifiers: open, public, internal and private. Access modifier below the public level would have a special optional limit (file) to bound them to a file. It allows to declare type private extensions in different files, which a lot of people would like to achieve without the need to expose the API as internal to other types. Furthermore it allows better testability with the potential future inline unit tests.
One could potentially extend the limits to allow scoped access but that's a different story (e.g. (scope)private).