visibility vs. accessibility of protected symbols

[Jonathan M Davis]

On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:

> Well, not being able override what cannot be accesses is a quite basic
> requirement of security. Private members cannot be overriden in a
> different module.

Have you ever read up on NVI? That's how it's supposed to work. The whole idea 
is to have derived classes override functions without being able to use them. 
It makes it so that the public function is non-virtual and contains whatever 
stuff you want to guarantee is called before or after the private function, 
which is then virtual.

http://www.gotw.ca/publications/mill18.htm

> > The whole idea of overriding private for NVI is to allow derived classes
> > to override the private function's implementation but not call it.
> 
> This is confusing method implementation with overriding. I just read the
> relevant sections of TDPL:
> 
> "D fully supports NVI by providing _specific guarantees_ when
> *interfaces* use access specifiers."
> 
> It is an explicit special case because private wouldn't have much of a
> meaning for interfaces otherwise. This means private interface members
> would not be hidden, they are special _already_.

The fact that TDPL talks about interfaces in specific could be a good argument 
for _not_ making private virtual for classes. But regardless, as it stands, 
_nothing_ which is private is hidden. So, there's nothing special going on 
with interfaces and private, except that you can't override them to actually 
do NVI, so they're kind of pointless.

> > If private becomes virtual, then the compiler loses the ability to
> > inline non-final private functions unlessit can guarantee that it's
> > dealing with that exact type, which it
> usually can't do in the type's own member functions.
> 
> The optimisation works for all private class members. The issue is the
> virtual table layout for separate compilation with .di files, therefore
> it is not a good idea to make private methods virtual. But that is not
> required to satisfy TDPL anyway:
> 
> As far as I can see TDPL only requires private *interface* members to be
> implementable. That is not a problem at all, interface vtbls use
> thunking anyway. Therefore the private members could just be plugged
> there and be called virtually through base interface calls and
> non-virtually otherwise.

The optimization only works as long as the compiler can guarantee that no 
derived classes override the private functions, since it doesn't necessarily 
know about all of the derived classes. If D allowed NVI with classes the way 
that C++ does by making private virtual, then derived classes would _have_ to 
be able to override private functions in base classes which are in separate 
modules; they might even be in separate libraries. And then the compiler could 
not guarantee that no derived classes overrode the private functions, and the 
optimization could not be made. Hence why I'm arguing against making private 
functions virtual.

Personally, I'd very much like to see access level affect visibility, but 
Walter must be convinced.

- Jonathan M Davis