visibility vs. accessibility of protected symbols

[Timon Gehr]

On 02/14/2012 01:28 AM, Jonathan M Davis wrote:
> On Tuesday, February 14, 2012 00:36:31 Timon Gehr wrote:
>> On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
>>> On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
>>>> Can you elaborate on what issues you see with NVI. After all it's only
>>>> the final public
>>>> method that needs to call the virtual private methods.
>>>
>>> As I explain in that bug report, NVI can be acheived with protected
>>> rather than private. So, we can do NVI now with private being
>>> non-virtual. However, if we make private virtual, then the compiler can
>>> no longer inline private functions in classes unless they're marked as
>>> final. That's a performance hit to pretty much every class ever
>>> written.
>>>
>>> Yes, the conscientious programmer will mark their classes' private
>>> functions final unless they intend to use them for NVI, but the
>>> _default_ is then inefficient for little to no gain. All you gain is
>>> the ability to do NVI with private instead of protected, and that is
>>> not even vaguely worth the performance hit to almost every D class ever
>>> IMHO.
>>>
>>> - Jonathan M Davis
>>
>> Virtual private does not allow for cross-module NVI, so what would be
>> the point anyway?
>
> Why wouldn't it? The whole point of NVI is that you override it but don't call
> it - the base class does that. So, the derived class could override the
> private function but couldn't call it. It _is_ a bit weird though, all the
> same.
>

It would break information hiding. A private method declared in a 
different module is not supposed to be visible (hopefully will get 
fixed), let alone overrideable.

> Regardless, I'm against making private virtual because of the needless
> performance hit.
>

There are no performance implications because the compiler has the whole 
module ready to analyse. Therefore it can de-virtualise any calls to 
private members that are never overridden. A trivial addition to the 
class layout could furthermore allow the compiler to remove the vtable 
entry for such a member function entirely (essentially, virtual private 
members would get negative vtable offsets). I actually think that should 
be implemented in order to get a potential TDPL error off the table.