Private visible?

[Dave]

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

I don't wish to belabor this, but it would seem that the above great 
reasons for "visible but not accessible" conflict with the current 
behavior described here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/7649

So there are probably some bugs in there, especially with regard to #3 
above and #2 in Kris' post. This to me is a before 1.0 thing.

Thanks,

- Dave