visibility vs. accessibility of protected symbols

[Jonathan M Davis]

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.

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.

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.

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

> > 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. The whole 
idea of overriding private for NVI is to allow derived classes to override the 
private function's implementation but not call it. If private becomes virtual, 
then the compiler loses the ability to inline non-final private functions 
unless it can guarantee that it's dealing with that exact type, which it 
usually can't do in the type's own member functions.

- Jonathan M Davis