Bug 1441 – [module] Allow 'private' to restrict class visibility outside module or outer class

Currently, there is no way to restrict a class from being visible outside the module where it is defined, or for inner classes, outside its outer class. This isn't a bug, more of a feature request, but it would be nice to be able to use 'private' on a class to hide its visibility: module A; private class Foo { ... } module B; import A; Foo f = new Foo; // error, Foo is private also: class Foo { private static class Bar { ... } ... } Foo.Bar b = new Foo.Bar; // error, Bar is private I know a private constructor can be used to prevent a class's *instantiation* from another module, but this seems like a hackish workaround to me. Modules should be able to prevent their classes from being visible in another module for at least two reasons: 1. Encapsulation: for the same reasons that private methods of a class aren't visible when its containing module is imported, classes that are part of the implementation of the module aren't visible when the module is imported. 2. Namespace pollution: modules can prevent names that are part of their implementation from unneccessarily entering the namespace of an importing module. The same applies to inner classes. Thanks, Nathan Reed

This has resurfaced as issue 2830. I say this is a bug - the compiler shouldn't be allowing the use of attributes that aren't meant to work.

That's an entirely separate issue from this enhancement request. The spec also does not say that 'pointless' attributes should trigger an error, so I don't see how it's "accepts-invalid" at all.

(In reply to comment #2) > That's an entirely separate issue from this enhancement request. The spec also > does not say that 'pointless' attributes should trigger an error, so I don't > see how it's "accepts-invalid" at all. 1. http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute talks of "members". Should we interpret this to include arbitrary members of a module? 2. Where does the spec state that it's legal to use attributes that are not applicable to the entity to which they're applied? Otherwise it's reasonable to assume that, should the compiler fail in its attempt to apply an attribute to something, this failure is supposed to be by means of generating an error. 3. Making a class or similar entity private makes perfect sense. Silently ignoring attempts to do so makes absolutely none.

(In reply to comment #3) > 1. http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute > talks of "members". Should we interpret this to include arbitrary members of a > module? Sure. That's more or less what this ticket is suggesting. > 2. Where does the spec state that it's legal to use attributes that are not > applicable to the entity to which they're applied? Otherwise it's reasonable > to assume that, should the compiler fail in its attempt to apply an attribute > to something, this failure is supposed to be by means of generating an error. Two problems. One, the spec is silent on this issue, so it's logically inconsistent to conclude that by not issuing an error, the compiler is acting incorrectly. In effect there is no "correct" behavior because there is no specified behavior; assumptions mean nothing. Two, if you want the compiler to give an error about inapplicable attributes, put it in another ticket. That particular behavior encompasses far more than just public and private on classes, but also things like final, static, extern etc. > 3. Making a class or similar entity private makes perfect sense. Silently > ignoring attempts to do so makes absolutely none. Again, what the compiler should do with inapplicable attributes is a separate issue from what 'private' on a class should mean. This ticket is an enhancement request; your request is more one for clarification of the spec.

Discussion taken to: "The great inapplicable attribute debate" digitalmars.D:87915 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=87915

*** Issue 6180 has been marked as a duplicate of this issue. ***

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a75022643a7f6758074f8b107a2c37eb1231e3f8 fixed Issue 1441

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e37a34ff5afdd41a2f064a318f5696394a43e9fc Revert "fixed Issue 1441" This reverts commit a75022643a7f6758074f8b107a2c37eb1231e3f8.

From original Nathan's post there are 2 cases, first looks similar to http://d.puremagic.com/issues/show_bug.cgi?id=2830 (originally for D2 and now for D1 only) The fix from commit https://github.com/D-Programming-Language/dmd/commit/6a8be065d8eda64318643147704aebdcc22fd7b8 effectivelly solves the issue on module level for D2.061 alpha. The same time for the case of private nested classes which are still accessable outside of enclosing class and module. The behaviour should follow "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class." in http://dlang.org/attribute.html. While this effectively allows access to private nested members from inside the same module, http://dlang.org/class.html "A nested class is a class that is declared inside the scope of a function or another class" closing visibility and access to nested members outside of function or enclosing class even the same module. The issue is moved from "enhancement" to the bug.

The issue of cross-module private symbols has been fixed. The issue regarding nested classes is invalid - protection in D has module-level granularity. If I'm missing something, please reopen with a precise description of the balance of the problem. Thanks.