Module-level accessibility

[Jonathan M Davis]

On Wednesday 06 October 2010 04:04:24 Steven Schveighoffer wrote:
> On Tue, 05 Oct 2010 20:27:58 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > Well, I don't see why it wouldn't be possible for the compiler to
> > enforce that
> > overridden private methods can't be called by anyone but the base class.
> > That
> > being the case, then allowing for private virtual functions is most
> > definitely
> > useful. However, if it really isn't possible to restrict it so that
> > derived
> > classes can't call the private methods that they've overridden, then I
> > do agree
> > that we might as well just stick to using protected and make private
> > functions
> > unoverridable. But if we _can_ make it so that derived classes can't call
> > overridden private methods, I think that that would be valuable and
> > desirable.
> 
> See my earlier post -- if you control the implementation, the compiler
> cannot prevent you from calling it.  Even if it tries...
> 
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&a
> rticle_id=118350
> 
> So you gain nothing, but annoyance (*grumble* now I have to split my
> implementation from the virtual function just to be able to call it?).
> 
> -Steve

I do not see why the compiler cannot enforce that a function which overrides 
another function which is private cannot be called by the derived class even 
though the implementation is in the derived class. It may not do so now, but I 
don't see why it couldn't do so. It's already supposed to enforce that the 
access level of the derived function isn't more restrictive than the base class' 
function. You'd just make it so that it wouldn't allow it to be called either if 
the access level were private.

- Jonathan M Davis