Private visible?

[Ivan Senji]

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

If I am using a library do I really need to get error messages about 
private functions from that library? To me this sounds not only like a 
bad design of that library but also of the language that allows it.

As others said mixing various protections on different functions of the 
same name is most of the times a bad design. But if it isn't and it is 
intentional, then what is the point in getting an error that something 
is private. If something is private isn't it then meant not to be seen?

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

Various 'poisoning' techniques sound a lot like C++ to me. There one can 
make classes that can not be constructed, can not be inherited from, can 
not be passed by value, cannot be allocated on stack and many different 
things by making something that is private. But are these techniques 
realistic or even possible in D?

I don't know what to do about 3) but is this the way to do things in D 
as is in C++?