Bug 206 – attributes private, package, etc appear to be ignored

Attributes marked as 'private' to one module are perfectly visible to all others. It appears 'package' has a similar problem. Perhaps 'protected' too ?

The original bug report uses the word 'visibility' when in fact 'accessibility' was meant. Here is a code example that compiles okay but it should not... //----- file qwerty.d ---------- module qwerty; private void foo() {} // ---EOF--- //----- file mod.d ------------- module mod; private import qwerty; private void bar(){} // ---EOF--- //----- file test.d ------------- import mod; void main() { mod.bar(); // 'bar' is supposed to be private to mod. qwerty.foo(); // 'qwerty' is supposed to be private to mod. // 'foo' is supposed to be private to qwerty. } // ---EOF--- Compile this with ... dmd test.d mod.d qwerty.d If you change the test.d file to remove the module qualifiers, it fails to compile, which is correct. //----- file test2.d ------------- import mod; void main() { bar(); foo(); } // ---EOF--- Now when compiled we get .... test2.d: module test2 mod.bar is private test2.d(5): undefined identifier foo test2.d(5): function expected before (), not foo of type int

Duplicate... *** This bug has been marked as a duplicate of 48 ***

This is *not* a duplicate of #48 -- read the descriptions carefully. #48 actually has the basic visibility operable and enabled (in march 2006), but allows one to step around visibility by fully qualifiying. Since then, the basic visibility mechanism has broken down completely.

Bruno's comment in Bug 48 addresses this issue as well, however. And it's likely they're both the same issue, caused by the same code in the compiler. I'd argue that we stick with 48.

It's a possibility, but a bit vague for my tastes. I'd argue that (a) Derek's examples are notably superior, (b) the report is certainly related at some level, but clearly identifies a different aspect (in the example) than the earlier report, and (c) the more reports on this, the better :)

Fixed DMD 0.163.