On Tue, Jan 16, 2018 at 06:13:27PM +0000, rumbu via Digitalmars-d-learn wrote: > module a; > > private import std.math: isNaN; > > //custom overload > public bool isNaN(int i) { return false; } > > > ============================= > > module b; > import a; > > void foo() > { > bool b = isNaN(float.nan); > //compiles successfully calling std.math.isNaN even it should not be > visible. > } > > Is this normal behavior or a bug?
Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed. > OK, let's try another: > > module b; > import a; > import std.math; // <== note this > > void foo() > { > bool b = isNaN(float.nan); > } > > It ends in a very funny error message: > > Error: std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335) conflicts > with std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335) [...] LOL! Yeah, if this is the latest compiler, it's definitely a bug. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.