visibility vs. accessibility of protected symbols

[Timon Gehr]

On 02/14/2012 03:54 AM, Jonathan M Davis wrote:
> On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
>> 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.
>
> I'm not aware of _any_ difference between virtual functions in C++ and D except
> for the fact that all public and protected member functions are always virtual
> in D (unless the compiler is able to determine that it can make them non-
> virtual), and currently private and protected functions are never virtual.
> What differences are you referring to?
>
> - Jonathan M Davis

The main difference is that C++ has an explicit 'virtual' modifier that 
naturally grants override-access to private symbols.