http://d.puremagic.com/issues/show_bug.cgi?id=1441

           Summary: Allow 'private' to restrict class visibility outside
                    module or outer class
           Product: D
           Version: 2.003
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: nathaniel.reed@gmail.com


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


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Keywords|                            |accepts-invalid




------- Comment #1 from smjg@iname.com  2009-04-10 12:40 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441





------- Comment #2 from jarrett.billingsley@gmail.com  2009-04-10 14:05 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441





------- Comment #3 from smjg@iname.com  2009-04-10 14:34 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441





------- Comment #4 from jarrett.billingsley@gmail.com  2009-04-10 14:45 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441





------- Comment #5 from smjg@iname.com  2009-04-12 17:53 -------
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


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1441


Christian Kamm <kamm-removethis@incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #6 from Christian Kamm <kamm-removethis@incasoftware.de> 2011-08-20 23:22:20 PDT ---
*** Issue 6180 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1441



--- Comment #7 from github-bugzilla@puremagic.com 2012-02-18 11:04:42 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a75022643a7f6758074f8b107a2c37eb1231e3f8 fixed Issue 1441

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1441



--- Comment #8 from github-bugzilla@puremagic.com 2012-02-18 11:47:24 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1441


Oleg Kuporosov <Oleg.Kuporosov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Oleg.Kuporosov@gmail.com
         OS/Version|Linux                       |All
           Severity|enhancement                 |major


--- Comment #9 from Oleg Kuporosov <Oleg.Kuporosov@gmail.com> 2012-10-18 02:33:19 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------