visibility vs. accessibility of protected symbols
timon.gehr at gmx.ch
Mon Feb 13 17:43:29 PST 2012
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.
> 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
> 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
More information about the Digitalmars-d