Should protection attributes disambiguate?

[Jonathan M Davis]

On 2011-06-21 09:00, so wrote:
> On Tue, 21 Jun 2011 18:43:51 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > ???
> > 
> > private import a;
> > 
> > and
> > 
> > import a;
> 
> Uh, yeah you are right. I meant something like:
> 
> module base1;
> private struct base;
> struct base1 : base {
> }

In such a case, the current implementation complains if you try and use base, 
which is exactly what it should be doing. It'll tell you that base is private 
and that you don't have access to it. If it were completely hidden, then the 
error message would end up saying something about base not existing, which 
could be far more confusing, since base _does_ exist. The issue here is that 
if you had your own base which you imported from another module, the compiler 
is going to complain about that base and base1.base clashing instead of 
assuming that you meant your base, since base1.base is private. All that is 
required here is adjusting how symbols collisions are dealt with when one of 
the symbols is private. There's no need to adjust how access modifiers work 
globally. And there are _definitely_ people out there who think that NVI 
justifies visibility without access. But regardless of that, I believe that 
that's how public and private work in every C-derived language which has them. 
The exact implications of that may very from language to language depending on 
what they do or don't allow you to do, but as far as I know, access modifiers 
are always _access_ modifiers and not visibility modifiers.

- Jonathan M Davis