------- Comment #6 from  2009-01-20 14:53 -------
(In reply to comment #5)
> See issue 2524 comment 8.  However, this brings us back to the problem of
> inheritance protection, previously brought up in issue 177 and issue 2563.  We
> already have why it doesn't make sense for classes in D; it doesn't make sense
> for interfaces for a different reason.  The point of private inheritance is to
> implement an "implemented in terms of" relationship, but interfaces contain no
> implementation.  So the "implementing" class would gain nothing over not
> implementing the interface at all.  I think the same would apply to protected
> inheritance....

My interpretation of the spec is that private methods are never virtual and
never go into a vtable.  As stated by the spec the exact set of functions that
are virtual are: "All non-static non-private non-template member functions are

It is impossible for a static, template, or private function to be virtual,
which means it cannot be in a vtable.  final methods can be virtual (meaning
they are in a vtable), they just cannot be overridden.

I would propose that it should be an error to implement an interface with
private protection.  It makes no sense, as an interface is used where you do
not know the implementation, but a private symbol can only be used in the file
it's declared in, so you *should* know the implementation by looking at the


Reply via email to