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?

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)

Real life context:

the private import: https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L320

the overload:
https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L4201

If the end user wants to use my module like this:

import std.math;
import decimal;

he'll get the nice error message above.
	

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.

On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:

> 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.

2.078, but also 2.077. Deprecation is emitted only if there is no overload;

>
> 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.

Done: https://issues.dlang.org/show_bug.cgi?id=18243

On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote:
> On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:
>
>> 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.
>
> 2.078, but also 2.077. Deprecation is emitted only if there is no overload;
>
>>
>> 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.
>
> Done: https://issues.dlang.org/show_bug.cgi?id=18243

1) Imports are by default private
2) This is a known bug. See:

https://github.com/dlang/phobos/pull/5584
https://issues.dlang.org/show_bug.cgi?id=17630

On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668

On Wednesday, 17 January 2018 at 02:23:40 UTC, Seb wrote:
> On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote:
>> On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:
>>
>>> 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.
>>
>> 2.078, but also 2.077. Deprecation is emitted only if there is no overload;
>>
>>>
>>> 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.
>>
>> Done: https://issues.dlang.org/show_bug.cgi?id=18243
>
> 1) Imports are by default private
> 2) This is a known bug. See:
>
> https://github.com/dlang/phobos/pull/5584
> https://issues.dlang.org/show_bug.cgi?id=17630
>
> On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668

Are you sure about this?  I thought such module-scope selective imports were supposed to be private by default since Martin's fixes for bug 314, which is why you submitted pull 5584.  Bug 17630 is about something different, that selective imports pull symbols out of the imported module's non-selective imports, but he's not using any selective imports in his module b.

I ran this code example through my symbol-dumping dmd (http://forum.dlang.org/thread/pbpckzwmfglzgwqveoza@forum.dlang.org) and module b from his first example is indeed getting isNaN from std.math, which implies the older bug that selective imports at module scope are still leaking out.

On Wednesday, 17 January 2018 at 07:40:36 UTC, Joakim wrote:
> Are you sure about this?  I thought such module-scope selective imports were supposed to be private by default since Martin's fixes for bug 314, which is why you submitted pull 5584.  Bug 17630 is about something different, that selective imports pull symbols out of the imported module's non-selective imports, but he's not using any selective imports in his module b.
>
> I ran this code example through my symbol-dumping dmd (http://forum.dlang.org/thread/pbpckzwmfglzgwqveoza@forum.dlang.org) and module b from his first example is indeed getting isNaN from std.math, which implies the older bug that selective imports at module scope are still leaking out.

Well the problem is that DMD doesn't perform no checks whatsoever when you do selective imports. So yes, I think both bugs are related.
However, I re-opened 18234 as we want to include the test case to the testsuite gets fixed.

BTW it's a shame that https://github.com/dlang/dmd/pull/6676 which will be pulled soon while being very close to the bugs in question, doesn't fix either of them.