Somebody above said that when pulling your deps for the first time, compiling your project yields a huge amount of warnings – and the warning you talk about will be drowned in them. Don’t get me wrong: I’d mercilessly pursue any and all warnings and fix them but (a) package maintainers aren’t always responsive and (b) I have to prioritize my paid work. All of us have only so much brain and finger cycles per day.
This is only one of its goals. In any and all of the 8 programming languages I worked with, private/protected functions are also used to express the intent of “here be dragons”, namely “this here is an implementation detail, you should not ever use this by yourself, please use my public API functions”.
Additionally, in corporate teams it is also being heavily utilized to limit the possibility of unintended dependencies – f.ex. a colleague from another team scans your internal company repo, finds the perfect function to do their job and before you know it, you have 2 team leads and 10 angry developers at your door because you changed a critical API their apps can’t work without.
When this proposal gets implemented, I’ll use it to enforce boundaries in my code, be it internal corporate big mono-repos, or public open-source libraries.
This also has the added benefit of encouraging discussion of yours / somebody else’s code.
