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();

Reply via email to