On 2011-06-21 09:00, so wrote: > On Tue, 21 Jun 2011 18:43:51 +0300, Jonathan M Davis <[email protected]> > > 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
