www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4533] New: Ban public aliases to private symbols

reply d-bugmail puremagic.com writes:
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



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: -------
Jul 29 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4533


Nick Sabalausky <cbkbbejeap mailinator.com> changed:

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



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: -------
Jul 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4533


Leandro Lucarella <llucax gmail.com> changed:

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



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: -------
Jul 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4533




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:


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: -------
Jul 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4533




05:04:59 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



 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: -------
Jul 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Aug 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4533




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?


Good catch. I opened bug 4545.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 01 2010
prev sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jan 31 2012