traits getProtection

[Jonathan M Davis]

On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
> It's all nice and well, but I believe part of the reason of say private
> protection is that user is never ever able to see(!) it. Thus it user
> can't depend on private members being there, which is a good thing.
> If I read it right, the technique you present allows user code to depend
> on private functions being there.
> I argue that we shouldn't even provide a _possibility_ for external
> stuff to depend on private members.
> Same argument in limited scope goes for protected.

As it stands, private has _no_ effect on symbol visibility. All it affects is 
symbol accessibility. For instance, if you create a private alias in a module, 
it affects every module that imports your module, or if you create a function 
which causes an overload conflict, it creates an overload conflict regardless of 
whether it's private or not. C++ is the same way. Access modifiers are just 
that, _access_ modifieres. They _only_ affect accessibility, not visibility.

Now, there are a number of people very unhappy about this state of affairs and 
want private to hide symbols as well (personally, I think that the fact that 
it makes private aliases effectively useless is reason enough to seriously 
reconsider the current behavior), but I don't know if there's any real chance 
of convincing Walter or not.

- Jonathan M Davis