On Wednesday, 19 July 2017 at 11:52:09 UTC, John Burton wrote:
---- lib1.d ----
private void init()
{
// init function used only as an implementation detail
}
void mything()
{
init();
}
---- lib2.d -----
void init()
{
// init function meant to be used as part of the module
interface
}
---- main.d ----
import lib1;
import lib2;
void main()
{
init(); // This is meant to call lib2.init because it's
the only
// function of that name. lib1.init() is supposed
to be
// an entirely internal implementation detail of
lib1
// Even though I can't call lib1.init() because
it's private
// this call still shows up as ambigous.
//
// In C I'd write "static void init()" in lib1.d
to indicate
// that the function was entirely local to that
file. However static
// does not appear to have that same effect in D
}
This should work as you expect, as that's what private in module
scope is supposed to do. And it does work for me 2.074.1. There
was a bug with the visibility of module-private symbols in the D
frontend that was fixed a couple of releases back (can't recall
off hand which version). So if you're using an older version of
DMD, or a version of LDC or GDC that uses an older version of the
frontend, then you'll still encounter the bug.
The workaround (until you get a compiler with a more recent
frontend) is to use the fully qualified name (FQN) of the
function you want to call, in this case: lib2.init();