This isn’t the only problem this proposal solves. As many others have said, even within the same application, maintained by the same team, this proposal helps outline boundaries for future uses of the code. Edit: I have updated the proposal to list this as well.
Also, I have had in multiple instances to maintain code that I was really not supposed to, nor didn’t want to, to not break other people’s code that were accidentally using private APIs. It is easy to see how this is not healthy in the long term: it discourages the team to bring more improvements while increasing the maintenance burden.
So saying this only aids with the public perception is not true. Especially because, it is not about even about perception, since those applications are actually broken on updates due to transitive dependencies. This is mentioned directly in the proposal: “Even more worrying, is that this practice in the long term can be really harmful as systems grow in size”.
Isn’t improving the language so we can better communicate between teams and users about our boundaries a way to use technology to improve what is inherently a people’s problem? What are the other suggestions then to solve this problem? How can we better reveal intent about the use of “private” modules given the current mechanisms are clearly not enough?
