Bug 7236 – Protected class members in different file inaccessible
Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-01-05T14:50:00Z
Last change time
2013-02-04T11:16:08Z
Keywords
pull
Assigned to
andrej.mitrovich
Creator
full.demon
Comments
Comment #0 by full.demon — 2012-01-05T14:50:24Z
Example:
a.d:
class A
{
protected:
void f()
{
}
}
main.d:
import a;
class B: A
{
public:
void g(A a) // using g(B b) it works
{
a.f(); // error
}
}
int main()
{
auto b = new B;
b.g(b);
}
dmd main.d a.d
Error: class a.A member f is not accessible
This is ONLY if A is in a different file (else B can access any of A its members due to module accessibility). If g accepts B instead of A it works though.
Comment #1 by lovelydear — 2012-04-19T13:51:25Z
Confirmed on 2.059
Comment #2 by lovelydear — 2012-04-21T01:47:16Z
I think this is a major bug.
Comment #3 by lovelydear — 2012-04-21T02:28:51Z
It also works with the following calls: f(), this.f() and super.f()
Comment #4 by lovelydear — 2012-04-23T02:22:36Z
See also on the same topic issue 5769
Comment #5 by andrej.mitrovich — 2013-01-13T09:58:51Z
This is exactly the way it is designed to work. Accessibility is determined by the 'this' pointer, not the function it is in (C++ operates the same way). And, of course, code in a module has all access to other classes in the same module.
Comment #7 by andrej.mitrovich — 2013-02-04T11:16:08Z
(In reply to comment #6)
> This is exactly the way it is designed to work. Accessibility is determined by
> the 'this' pointer, not the function it is in.
Perhaps, but it could be a future enhancement. I'm not sure about the pros vs cons, maybe encapsulation would break under this enhancement. The damage seems limited though.