Bug 24388 – Private overload of public function can be called from other modules

As of DMD 2.107.0, the following program compiles and runs without errors: --- lib.d module lib; import std.stdio; private void fun(int) { writeln("int"); } public void fun(string) { writeln("string"); } --- app.d module app; import lib; void main() { int n; fun(n); } --- The output is: --- int --- Even thought lib.fun(int) is private, it is able to be called from the app module as long as lib.fun(string) is public. Unlike in issue 23947, the order of the lib.fun overloads does not matter here.

Looks to be a duplicate of issue 3254.

It's not the same bug as the original report in 3254 (that one is order-dependent, this one isn't). However, it looks like 3254 has been repurposed since its reopening in 2022 to refer to the bug described here, since other issues that are exact duplicates of this one have been marked as duplicates of 3254.

@Paul, initially, the issue was that you could call the private overload if the public one was the first in the overload set. Then some "progress" has been made by getting rid of the order dependency, however, the issue of being able to call the private overload remains (that is why the issue was reopened). To me, it looks like the original bug which caused 3254 was not fixed properly, therefore it makes sense to keep that original one open and mark this one as a duplicate.

Also, I tried to fix this in the past, however, the issue is that private functions that are part of an overload set can be called from templated functions if they are passed via an alias template parameter. Some people argue that this is a valid use case because a single private function can be called from a templated function that way. For more info on this discussion see: https://github.com/dlang/dmd/pull/13257

As a general rule, I don't think that "the attempted fix for bug X ended up causing bug Y" is a good reason to consider Y a duplicate of X. But since the decision to do so has already been made in this case, I'm fine going along with it here. *** This issue has been marked as a duplicate of issue 3254 ***