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

           Summary: Ban public aliases to private symbols
           Product: D
           Version: D1 & D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: tomeksowi@gmail.com


--- Comment #0 from Tomasz Sowiński <tomeksowi@gmail.com> 2010-07-29 13:59:12 PDT ---
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.

-- 
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=4533


Nick Sabalausky <cbkbbejeap@mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbkbbejeap@mailinator.com


--- Comment #1 from Nick Sabalausky <cbkbbejeap@mailinator.com> 2010-07-29 16:04:27 PDT ---
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/digitalmars-d@puremagic.com/msg34092.html

-- 
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=4533


Leandro Lucarella <llucax@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llucax@gmail.com


--- Comment #2 from Leandro Lucarella <llucax@gmail.com> 2010-07-29 16:54:37 PDT ---
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 :)

-- 
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=4533



--- Comment #3 from Tomasz Sowiński <tomeksowi@gmail.com> 2010-07-30 13:52:33 PDT ---
(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;

-- 
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=4533



--- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-07-31 05:04:59 PDT ---
(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.

-- 
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=4533


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

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


--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2010-08-01 07:10:23 PDT ---
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?

-- 
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=4533



--- Comment #6 from Tomasz Sowiński <tomeksowi@gmail.com> 2010-08-01 07:57:18 PDT ---
(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.

-- 
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=4533


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |rejects-valid
                 CC|                            |dawg@dawgfoto.de


--- Comment #7 from dawg@dawgfoto.de 2012-01-31 14:27:04 PST ---
This should be fixed to work with functions as it already works for other declarations.

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