Private visible?

[Sean Kelly]

Walter Bright wrote:
> Dave wrote:
>> Everyone seems to agree that 'private' should not be accessible and 
>> the current behavior is a bug. What we're all wondering is if 
>> 'private' can also mean 'invisible' because that seems to be more 
>> intuitive. Than you don't have that extra level of complexity for 
>> lookup resolution and things like error messages describing a private 
>> interface.
> 
> The original reason why private members would be visible but not 
> accessible has been forgotten. However, there were some significant 
> issues brought up with making them invisible:

Thank you very much for looking into this.

> 1) function overloading - if various overloads of a function have 
> different protections, different functions will be selected even though 
> the same arguments are presented. This can be surprising when code is 
> moved around. If they are visible, you'll get an error message instead 
> of silently varying behavior.

I would assert that mixing protection attributes on overloads is Bad 
Programming.  Further, I think the principle of least surprise may not 
be a particularly strong argument here because the truly surprising 
behavior seems to be that private symbols are considered at all.  That 
the current C++ behavior has been elevated to the status of a newbie FAQ 
question is ample evidence here.

> 2) function overloading - one could lose the ability to 'poison' an 
> operation on certain argument types, because instead the private 
> function will not be seen and another selected.

So basically intentionally exploiting the above behavior to prevent 
certain implicit conversions from occurring if the programmer does not 
have access to the base class (where it may be possible to add an 
'explicit' in C++).  Is this practice at all common?  And how much does 
it apply to D, given D's far simpler overload resolution mechanism?

> 3) function overriding - if a private function in a derived class 
> overrides a public one in a base class, this overriding will not happen 
> if the private function is invisible. Not only does this break 
> encapsulation, it prevents the design pattern of being able to 'poison' 
> certain operations on a class.

Perhaps there should be some discussion of what 'private' means in D 
compared to C++.  For example, private functions in D are not 
overridable, but they are in C++.  I think this represents a somewhat 
fundamental departure from the C++ mindset, and perhaps warrants a 
different interpretation of how symbol resolution should be handled. 
Also, we have the benefit of weighing nearly 20 years of experience with 
the C++ mechanism, which I suspect had to be considered in purely 
hypothetical terms when the original decision was made.

In hindsight, does the C++ mechanism seem optimal for C++?  And is the 
language structure of D sufficiently similar to C++ that it is optimal 
for D, by extension?  I realize that these are difficult questions to 
answer, but I don't want to close the door on the idea just yet simply 
because the decision for C++ involved reasons that *may* also apply to 
D.  At the very least, it does seem clear that this behavior is 
confusing for novice programmers, and this is a red flag to me that the 
design may not be ideal.


Sean