Let me start by saying that I completely agree with the gist of your post, as I understood it: optimizing for the "physical" boundaries of a codebase, including the boundaries between teams working on the same product, is more important than obsessing over specific visibility rules of specific members of specific types.
But the available accessibility identifiers will inevitably drive the structure of a codebase when it comes to code ownership. For example, because I can define something as
fileprivate, I can make sure that the owner of that file, whether an individual or a team, will be informed and asked for permission if something changes there, and the owner can decide if some components declared in that file should be visible outside the file or not.
We can also take advantage of the concept of a "module" to enforce similar rules on a larger scale, so when a team owns a series of modules, it can use
public to decide what should be seen outside the modules, by other teams, for example.
The current situation has limitations, though:
- there's no way to enforce visibility across the modules owned by a team, but not outside;
- once in a module, there's no way to further split it in smaller domains, for simple code organization even if the owner is still a single team, or for clarifying the boundaries between subteams
package access modifier could help in this situation, but I think it will drive a specific way of using packages to distribute ownership among teams.
In our case, for example, there's a single app that's worked on by several teams. The app is modular, it contains some packages related to layers of the architecture, within which there are modules assigned to different teams, and we use folders to organize the modules per team.
What we're missing right now is a way to further split large modules into smaller components, without them exposing stuff to the rest of the app, but at the same time being able to share code across them.
This could be done in several ways. The feature introduced by this proposal would compel us to turn what are currently modules into packages, so we could have smaller modules inside. But the package, as a tool, seems to be not just for code organization within an app, considering all the attributes of the manifest and the package resolution step in Xcode, so the proliferation of packages in the app might not really match well with our needs.
A different idea could be that of a "submodule", that is, essentially, a logical boundary within a the module itself, that, in following the "physical boundaries matter" approach, could be realized with something like
folderprivate, which I personally think would be a great idea.
So, I'm not opposed to the
package modifier at all: I'm just saying that for large projects that are worked on by multiple teams, it might not be the right tool for the job, and could produce an unnecessary package proliferation just for team ownership needs.