Should protection attributes disambiguate?

[Jonathan M Davis]

On 2011-06-21 05:40, so wrote:
> On Tue, 21 Jun 2011 06:04:28 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > It matters for stuff like NVI (Non-Virtual Inheritance). In that
> > particular
> > case, you overload a private function but you can't call it. You couldn't
> > overload it if you couldn't see it. So, there _are_ cases where it
> > matters,
> > and it _is_ an important distinction. It's just that it matters
> > infrequently
> > enough that most people don't realize that there is such a distinction.
> > But
> > distinction or not, I don't see why we couldn't just make it so that any
> > attempt to use a symbol where the clashing symbol can't be used anyway
> > just
> > doesn't clash by ignoring the private symbol in such cases.
> > 
> > - Jonathan M Davis
> 
> Good example, is it only this or are there any others?
> I am asking because i think this particular use case doesn't justify
> visibility but not access.
> If i got it right, we are talking about something like this:
> 
> module base1;
> private import base;
> struct base1 : base {
> }
> 
> module base2;
> import base1;
> struct base2 : base1 {
> }
> 
> Shouldn't compiler just issue an error whenever base1 accessed outside of
> the module it belongs?
> With its current state, it just encourages bad design as far as i can see.
> First of all inheriting from a class/interface/struct that is imported
> private implies this new class is going to be an implementation detail,
> hidden from user. If it wasn't intended, why would you import it private?

???

private import a;

and

import a;

are identical. There is no difference. When you import that doesn't affect any 
modules that import you. Now, making an import _public_ affects other modules, 
because then anyone who imports you also imports the other module, but imports 
are private by default. So, I don't understand what you're saying here.

The compiler does issue an error when you try and use a symbol which is 
private to another module. The issue here is that if there's another symbol 
which clashes which you _can_ access, the compiler forces you to give its full 
path instead of assuming that you mean the public one (which you _can_ use) 
and not the private one (which you can't).

- Jonathan M Davis