test_module.d:
# module test_module;
#
# private
# {
#   const int A = 1;
#   enum { B = 2; };
# }

program.d:
# import test;
# void main()
# {  int i;
#    i = A; // Doesn't compile (Correct behaviour, A is private)
#    i = B; // Compiles (Incorrect, B is also private)
# }

Nick

I posted this two weeks or so ago and never got any response.  In the interest of making the world a better place (and D a better language), I'll agree with you that enums (as well as classes, structs, and unions) should actually be private if they are declared as such.

On Wed, 9 Feb 2005 22:46:16 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> test_module.d:
> # module test_module;
> #
> # private
> # {
> #   const int A = 1;
> #   enum { B = 2; };
> # }

In the above you are:
1- creating an instance of an int called A and assigning a value 1 to it.
2- declaring an unnamed enum which has 1 member B with a value 2.

I think that currently D does not apply 'private' to declarations, only instances, eg.
the enum above is similar to:

# private
# {
#   class A {
#   }
# }

Which declares a class called A which is not treated as 'private' either.

That said, if you say:

#   class A {
#     private this() {
#     }
#   }

D does stop you from instantiating the class.

The questions are:
1- is the above this a declaration or an instance or both?
2- should private apply to a declaration? or only an instance?

> program.d:
> # import test;
> # void main()
> # {  int i;
> #    i = A; // Doesn't compile (Correct behaviour, A is private)
> #    i = B; // Compiles (Incorrect, B is also private)
> # }

Regan

In article <opslynqtqc23k2f5@ally>, Regan Heath says...
>
>In the above you are:
>1- creating an instance of an int called A and assigning a value 1 to it.
>2- declaring an unnamed enum which has 1 member B with a value 2.
>
>I think that currently D does not apply 'private' to declarations, only instances

Ok, that is somewhat confusing and a bit limiting. What do you do if you don't want a declaration to be available outside the module? It looks like the only option is to put it in yet another module, and do a private import:

module A: enum { TEST = 1; }
module B: private import A;
program: import B; // TEST is unavailable

Nick

On Thu, 10 Feb 2005 14:36:45 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> In article <opslynqtqc23k2f5@ally>, Regan Heath says...
>>
>> In the above you are:
>> 1- creating an instance of an int called A and assigning a value 1 to it.
>> 2- declaring an unnamed enum which has 1 member B with a value 2.
>>
>> I think that currently D does not apply 'private' to declarations, only
>> instances
>
> Ok, that is somewhat confusing and a bit limiting. What do you do if you don't
> want a declaration to be available outside the module?

It doesn't seem to be a big problem, though I can understand the desire to not pollute the namespace with un-necessary symbols.

> It looks like the only
> option is to put it in yet another module, and do a private import:
>
> module A: enum { TEST = 1; }
> module B: private import A;
> program: import B; // TEST is unavailable

It doesn't stop them importing B themselves and using your declaration.

I guess we're saying private should apply to a declaration in the same way it applies to an instance, right?

Regan

Nick wrote:
> In article <opslynqtqc23k2f5@ally>, Regan Heath says...
> 
>>In the above you are:
>>1- creating an instance of an int called A and assigning a value 1 to it.
>>2- declaring an unnamed enum which has 1 member B with a value 2.
>>
>>I think that currently D does not apply 'private' to declarations, only  instances
> 
> 
> Ok, that is somewhat confusing and a bit limiting. What do you do if you don't

I'd instead call it a bug.

> want a declaration to be available outside the module? It looks like the only
> option is to put it in yet another module, and do a private import:
> 
> module A: enum { TEST = 1; }
> module B: private import A;
> program: import B; // TEST is unavailable
> 
> Nick
> 
> 

_______________________
Carlos Santander Bernal

In article <opslz02hd623k2f5@ally>, Regan Heath says...

>> module A: enum { TEST = 1; }
>> module B: private import A;
>> program: import B; // TEST is unavailable
>
>It doesn't stop them importing B themselves and using your declaration.

Nope. But the point was, as you said, to not polute the namespace.

>I guess we're saying private should apply to a declaration in the same way it applies to an instance, right?

Yes, thats what I'm saying.

Nick

Carlos Santander B. wrote:
| Nick wrote:
|
|> In article <opslynqtqc23k2f5@ally>, Regan Heath says...
|>
|>> In the above you are: 1- creating an instance of an int called A
|>> and assigning a value 1 to it. 2- declaring an unnamed enum which
|>> has 1 member B with a value 2.
|>>
|>> I think that currently D does not apply 'private' to
|>> declarations, only  instances
|>
|>
|>
|> Ok, that is somewhat confusing and a bit limiting. What do you do
|> if you don't
|
| I'd instead call it a bug.
|

http://digitalmars.com/d/attribute.html
# Private means that only members of the enclosing class can access
# the member.

1) instead of "class" it should read "module or class scope"

2) Are type declarations members? I didn't find anything about that.
If type declarations are members, this is a bug.
If they aren't member this is in my view a flaw in the specification.

Thomas

> 2) Are type declarations members? I didn't find anything about that.
> If type declarations are members, this is a bug.
> If they aren't member this is in my view a flaw in the specification.

And if this is how it's supposed to work, then.. sigh, Walter.  ;)