traits getProtection

[Martin Nowak]

On Mon, 02 Apr 2012 19:10:01 +0200, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> 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.
>
Access modification really makes sense for nested scopes.
After all you can have access to a value of a protected type.
In this case changing the visibility could lead to accidental
mismatches. This behavior is taken from C++ and it makes sense.

Due to the .h/.cpp separation you'll also have most of the
implementation symbols invisible. That's where the C++ model
doesn't really map to D if 'import everything' remains the default.