visibility vs. accessibility of protected symbols

[Timon Gehr]

On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
> On Tuesday, February 14, 2012 01:55:51 Timon Gehr wrote:
>> On 02/14/2012 01:28 AM, Jonathan M Davis wrote:
>> 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.
>
> You misunderstand then. Private symbols are most definitely visible. Access
> modifiers do _not_ affect visibility, only accessibility. Private symbols are
> visible _by design_. That's how it works in C++, and D inherited that. The
> whole point of this thread is to discuss whether access modifiers should affect
> visibility, but right now they _do_, and it's _on purpose_ that they do. It's
> not a bug.
>

It is a bug on purpose.


> As it stands, if I declare a private function which conflicts with a public
> function, the compiler will complain. For example, If I were to add a private
> abs function to std.file which took an int, then any module which imported both
> std.math and std.file would have to use std.math.abs instead of just abs,
> because there would be a conflict. The fact that std.file's abs was private
> wouldn't mean anything to overload resolution.
>

Borken.

> In fact, just recently, a private abs function was added to core.time for what
> it needed, and it caused problems. It had to be changed to _abs to not screw
> up std.math.abs.
>

Exactly what I am saying. This is laughable (!) and should vanish from 
Ds otherwise very sane approach at modularity.

> The whole point of this thread is to discuss whether access modifiers should be
> changed to affect visibility rather than access.
>

Most definitely yes. The only hindrance are implementation issues.

>>> 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.
>
> No. It can't. Because a derived class in an entirely different module could
> override the private function. private does _not_ affect visibility.

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.

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


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