visibility vs. accessibility of protected symbols

[Timon Gehr]

On 02/14/2012 03:05 AM, Jonathan M Davis wrote:
> 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
>

That article uses C++. It is not really a fair comparison, because in D 
there is no way to explicitly declare a method "private virtual", and 
D's private is different from C++'s private, and C++ has a different 
sub-typing and inheritance model. I think there are different design 
trade-offs at play.

But I can make better sense of your point of view now: When I was 
talking about virtual I meant just a function that has an entry in a 
vtbl and is invoked virtually, while you probably had C++'s semantics in 
mind.


>>> 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.
>

The fact that they cannot be implemented in a class that implements the 
interface seems to be a [TDPL] bug.


>>> 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.

The optimization works under the precondition that derived classes from 
a different module cannot override private member functions.

> 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.
>

Here you probably mean virtual as in C++. I agree.

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

I think there were some issues with overload sets, but I think overloads 
with differing accessibility should just be disallowed.