private selective import + overload = breaks accessibility rules

Joakim dlang at joakim.fea.st
Wed Jan 17 07:40:36 UTC 2018


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.


More information about the Digitalmars-d-learn mailing list