Bug 4533 – Ban public aliases to private symbols

This module compiles fine...: module A; private void foo(); public alias foo goo; ... but try to use goo...: module B; import A; void main() { goo(); } ... and an error comes up: Error: function A.foo is not accessible from B We had a long discussion on digitalmars.D whether visibility-expanding aliases should be functional or not. If they were allowed, in some cases (member functions) the very presence of the alias could alter the generated code (think of class invariants, exposing public members to exe/dll, etc). So the conclusion was to cut the problem in the nip and retain the primary idea of aliases as mere helper symbol references whose existence ought not to be manifested in binary code. In other words, an alias whose visibility > than aliased symbol should fail already on the declaration spot.

The opinion of the "should be allowed" side is that there are real cases where it's useful. Another option would be to allow it, but only for cases where it wouldn't affect code generation. In any case, the behavior of the compiler does need to be changed because it's currently disallowed but without a clear error message on the line where programmer tries create the alias. For reference, the newsgroup discussion is here: http://www.mail-archive.com/[email protected]/msg34092.html

The problem is, attributes in D are not as in Java, they can be applied to a lot of symbols, like: --- private int j; public: int i; // another bunch of stuff alias j k; --- Should the compiler complain at that alias? What about this: --- void f() {} extern (C): void g() {} // another bunch of stuff alias f h; --- Should the compiler complain about non-sense extern (C) alias? What about const? You can "revert" the extern (C) with extern (D) and public with private, but there is no "mutable" to revert const. This is a bigger problem on how attributes work in D, and there were some threads about the issue. And I'm not saying I'm against issuing error when attributes are applied to things that doesn't make sense, I'm just sharing some problems about the issue :)

(In reply to comment #2) > The problem is, attributes in D are not as in Java, they can be applied to a > lot of symbols, like: > > --- > private int j; > > public: > > int i; > // another bunch of stuff > alias j k; > --- > > Should the compiler complain at that alias? What about this: Of course, accessed from a different module it fails like my example. > --- > void f() {} > > extern (C): > > void g() {} > // another bunch of stuff > alias f h; > --- > > Should the compiler complain about non-sense extern (C) alias? What about > const? You can "revert" the extern (C) with extern (D) and public with private, > but there is no "mutable" to revert const. Yes, it should complain. I think it doesn't matter that there's no "revert". If it's wrong then apply a different attribute or move it outside the attribute scope or whatever, just fix it :) > This is a bigger problem on how attributes work in D, and there were some > threads about the issue. > > And I'm not saying I'm against issuing error when attributes are applied to > things that doesn't make sense, I'm just sharing some problems about the issue > :) I wasn't aware of problems with attributes in general, thanks for bringing this up. That just made me try: const alias char C; // C is char, not const(char) Also, you can alias members from *outside*, which seems pointless and weird: class A { void foo() {} } alias A.foo goo;

(In reply to comment #0) > This module compiles fine...: > > module A; > > private void foo(); > public alias foo goo; > > ... but try to use goo...: > > module B; > import A; > > void main() { > goo(); > } > > ... and an error comes up: > > Error: function A.foo is not accessible from B > So the > conclusion was to cut the problem in the nip and retain the primary idea of > aliases as mere helper symbol references This is how it works. It doesn't matter, whether the alias is public or not, alias is still public, it doesn't help you access private members, as you can access them directly: module B; import A; void main() { A.foo(); } I think, if you access only alias, in, say, some sort of metaprogramming, you won't touch foo and your code will be valid.

Is the following relevant to this bug report? In the docs (http://www.digitalmars.com/d/2.0/declaration.html), there's this code: void main() { struct S { static int i; } S s; alias s.i a; // illegal, s.i is an expression alias S.i b; // ok b = 4; // sets S.i to 4 } But this will compile. I'm not sure if it's relevant to this bug report or if I should open up a new one?

(In reply to comment #5) > Is the following relevant to this bug report? > > In the docs (http://www.digitalmars.com/d/2.0/declaration.html), there's this > code: > > void main() { > struct S { static int i; } > S s; > > alias s.i a; // illegal, s.i is an expression > alias S.i b; // ok > b = 4; // sets S.i to 4 > } > > But this will compile. I'm not sure if it's relevant to this bug report or if I > should open up a new one? Good catch. I opened bug 4545.

This should be fixed to work with functions as it already works for other declarations.

Protection has been turned into visibility, and having something that exposes publicly something that is originally private is a common use case. It now works correctly for all types, so closing as INVALID.