We just had a major debate and decision about access control in Swift 4, and after herculean travails we landed on the current design. Let’s not resurrect that debate, it is not going to change.
In particular, “protected” was extensively discussed, with strong arguments on both sides. If it is not already in the commonly proposed and rejected list, it probably should be.
The only part of access control we might plausibly look at would be if we introduce a concept of sub-modules, at which point it would be worth considering an access level for them. But even that is outside the scope of Swift 5.
I am quite certain the core team has neither the time nor inclination to return to this topic.
Please no. The first version of scope in Swift was perfect. Each time someone tries to make it more like Java breaks it more. The last time we got that sick private and fileprivate instead of the nice clean private before.
And big code files are a good thing. It’s annoying combing though dozens of files that are all interlinked to find the part you need.
Yes, Swift’s access control is deliberately lexical. private has poked holes in the overall design, but it’s here to stay. It has been said by others that one very good choice if we were to do it again would be to eliminate everything except public and internal. I’d very much like that. But what we have is here to stay.
If someone comes up with a significantly nicer name than fileprivate, however, I do believe that the offer is formally still open to reconsider that name. But that’s about all that can change at this point.
Occasionally, local has come to mind as an alternate fileprivate, but I've always either forgotten it or thought it would run afoul of the fact that some languages use it for their scoped private access level.