This is kind of a gray zone IMO.
When a binding is marked with public and export, it’s public API. In the case of a function, according to the following discussion, that means all methods are public API, too:
So “private methods”/“internal methods” do not exist as a concept, from that specific and formal perspective, it seems.
However, it is also true that many private methods do de facto exist, not only in packages, but also in Base (as already pointed out above). After all, both public and the exact meaning of public API was only introduced with Julia v1.11.
In any case, it is certain that private methods are a bad practice, because:
-
The concept seems to conflict with the new public API rules.
-
It introduces unnecessary concerns about method ambiguity.
-
It pollutes the output of reflection functionality such as
methods. -
Additional methods reduce compiler performance.
Regarding the specific method in question here, IMO it would be better not to rely on it, and it could perhaps be deleted if a PkgEval run indicates that action would not break any packages. The signature does not follow the usual searchsortedfirst interface, so I’d say the method is harmful punning, and might have been intended to be a separate function in the first place.