Private visible?

[Dave]

Lucas Goss wrote:
 > Walter Bright wrote:
 >>
 >> 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.
 >
 > Interesting. But if I use a third party library:
 >
 > import lib.thirdparty;
 > ...
 > commonFuncName() // error (declared in my module and in thirdparty)
 >
 > I would be dumbfounded. Especially when I look at there documentation 
and there is no "commonFuncName".
 >
 > I had some more thoughts... but I lost them in the midst of other 
responsibilities. I'll see if I can remember.
 >
 > Lucas

It will look for and use the one in your module. If it is in your 
library that is also imported, then you'd get something like:

mylib.d(123): function mylib.baz conflicts with otherLib.baz at 
otherLib.d(456)

Then right now you could alias or hopefully soon use the new import 
syntax to disambiguate.

- Dave