Should protection attributes disambiguate?

[Jonathan M Davis]

On 2011-06-20 19:45, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1064.1308621500.14074.digitalmars-d at puremagic.com...
> 
> > On 2011-06-20 17:36, Andrej Mitrovic wrote:
> >> On 6/21/11, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >> > That's not necessarily a bug
> >> 
> >> Maybe the naming of the issue is wrong, but it has to be a bug:
> >> http://d.puremagic.com/issues/show_bug.cgi?id=6180
> >> 
> >> If private symbols are not usable, then creating an object of a
> >> private class type is a pretty major bug, methinks.
> > 
> > Oh, yes. That's a bug. But having two symbols which clash where one is
> > private
> > and the other public isn't a bug. It may be a design decision which
> > merits revisiting, but as I understand it, it's a natural consequence of
> > the fact that access modifiers modify access, not visibility.
> 
> Isn't visibility a form of access?
> 
> Regardless, I think it's clear that the whole point of a private "access"
> modifier is to make things *private* and safely encapsulated. The current
> situation clearly breaks this. And since visibility without access is
> useless, I don't see any reason to even get into the subtle semantics of
> "visibility" vs "access" at all.

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