Bug 2563 – Derived class is implicitly castable to Base class when inherited privately

Status
RESOLVED
Resolution
WONTFIX
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
All
OS
All
Creation time
2009-01-07T14:02:00Z
Last change time
2012-10-09T17:41:02Z
Keywords
accepts-invalid
Assigned to
nobody
Creator
2korden
Depends on
5299

Comments

Comment #0 by 2korden — 2009-01-07T14:02:17Z
module A; class A1 { void foo(); } class A2 : private A1 { } module B; void main() { A2 a2 = new A2(); // a2.foo(); // Error: class A.A2 member foo is not accessible A1 a1 = a2; // This line should yield an error a1.foo(); // ta-dam! Private method invoked }
Comment #1 by jarrett.billingsley — 2009-01-07T14:10:21Z
Why is public/private/protected inheritance even supported? I think this is more a strange artifact in the compiler/grammar than anything else. When you don't have MI, anything but public inheritance is useless.
Comment #2 by spam — 2009-01-07T14:22:48Z
afaik public/private/protected inheritance is not supported in D it is just not prohibited to write it like in the sample though it always is publicly inherited. there should be a bug for enhancement to stop permiting this confusing syntactical feature.
Comment #3 by 2korden — 2009-01-07T14:29:17Z
(In reply to comment #1) > Why is public/private/protected inheritance even supported? I think this is > more a strange artifact in the compiler/grammar than anything else. When you > don't have MI, anything but public inheritance is useless. > No, it's useful to hide implementation details.
Comment #4 by smjg — 2009-01-07T15:36:18Z
(In reply to comment #2) > afaik public/private/protected inheritance is not supported in D it > is just not prohibited to write it like in the sample though it > always is publicly inherited. What do you believe is the reason that D grammar goes out of its way to allow this syntax? > there should be a bug for enhancement to stop permiting this > confusing syntactical feature. Issue 177 Notice the real reason the feature doesn't make sense: it hides the methods defined in Object, which are meant to be part of every class.
Comment #5 by smjg — 2010-03-17T13:19:28Z
*** Issue 3774 has been marked as a duplicate of this issue. ***
Comment #6 by yebblies — 2012-01-29T22:00:53Z
D1 only now, as of issue 5299 private inheritance is deprecated in D2.
Comment #7 by smjg — 2012-01-30T04:33:58Z
(In reply to comment #6) > D1 only now, as of issue 5299 private inheritance is deprecated in D2. But it hasn't actually _worked_ in D1 for some time, and the spec has never actually given its meaning. As such, it would be to the point to just remove it from the grammar or at least issue a warning when one tries to use it.
Comment #8 by yebblies — 2012-01-30T07:29:01Z
(In reply to comment #7) > But it hasn't actually _worked_ in D1 for some time, and the spec has never > actually given its meaning. As such, it would be to the point to just remove > it from the grammar or at least issue a warning when one tries to use it. Yes... I don't recall stating anything to the contrary. If you thing the same fix (or a different fix) should be applied to D1 please reopen the closed issue (or a new issue) with that information. This bug is about the protection issue.
Comment #9 by alex — 2012-10-09T17:41:02Z
Considering D1 is close to being discontinued and this feature is long deprecated in D2, I think it's safe to close this. I don't see anyone ever getting around to fixing it, so keeping it open is somewhat pointless. (Feel free to reopen if you disagree.)