Every class in D is inherit from the class 'Object'. D does not support multiple inheritance. But if I do this:
class D{
}
class T : private D {
}
Now this invariant is not true any more.
The functionality from Object is no more visible to a user of T.
e.g. container can complain, they cannot access opEqual.
I think the D spec is not logic in this point and the inheritance protection should be removed.
Comment #1 by bugzilla — 2006-06-09T03:50:25Z
If one needs to access members of the base class, it shouldn't be marked as private. The compiler behaves as designed to for private base classes.
Comment #2 by benoit — 2006-06-09T04:57:21Z
Is this a misunderstanding?
From the D-spec, section classes, first paragraph:
"The object-oriented features of D all come from classes. The class hierarchy has as its root the class Object. Object defines a minimum level of functionality that each derived class has, and a default implementation for that functionality."
Now, if one inherits protected or private from any class, the class 'Object' is no more visible. Thats my point. The compiler does it job right, but the spec is not logic in this point.
The second argument for removing this protection is that this doesn't make sense in a language without multiple inheritance. E.g. java does not have this protected. I think exactly because of this.
Private inheritance is good for a "implemented with" relation. This makes sense in C++, not in D. In D, a possible way is using mixins. (if bug 106 is fixed ;) )
Comment #3 by smjg — 2006-06-13T10:15:52Z
How is the lack of multiple inheritance a reason that it doesn't make sense?
I agree with your first reason that it doesn't make sense, namely that of hiding the functionality of Object. Moreover, Java also has the principle that all classes derive from Object, which is probably one reason that Java doesn't have inheritance protection.
Comment #4 by benoit — 2006-06-13T10:41:26Z
(In reply to comment #3)
> How is the lack of multiple inheritance a reason that it doesn't make sense?
A public inheritance is good for "is a" relationship. a private inheritance in C++ can be used for a "is implemented with" relationship.
you write a base class with some functionality, so the user can simply derive from and has this functionality available for a concrete implementation class.
But what is this for if you give the user of your class the restriction, not to be able to derive from another public baseclass. Than this is not useful, and so the functionality should be implemented better in an other way. A member object is allways possible (and used in java). Perhaps mixins can be a better solution for many cases.
Or do you know a use-case for this feature?
Comment #5 by smjg — 2006-06-13T10:45:50Z
No. I too think it's a rather pointless feature to have in D.
Comment #6 by onlystupidspamhere — 2007-11-13T15:49:03Z
FWIW, I don't think there's much to fix other than the spec since this hasn't ever worked (DMD seems to be quite liberal in accepting attributes almost anywhere, but it doesn't mean it enforces anything) and nobody has requested this as far as I know. Also bug #1351 points out that export attribute doesn't even make sense.
Mixins and composition indeed solve "is implemented with" relationship and interfaces can be used to enforce a specific functionality.
Comment #7 by smjg — 2011-07-24T09:44:36Z
I wish we had a REDUCED resolution, which takes an issue number in the same way as DUPLICATE. Meanwhile, for want of that....
*** This issue has been marked as a duplicate of issue 5299 ***