On 2011-06-20 19:45, Nick Sabalausky wrote: > "Jonathan M Davis" <[email protected]> wrote in message > news:[email protected]... > > > On 2011-06-20 17:36, Andrej Mitrovic wrote: > >> On 6/21/11, Jonathan M Davis <[email protected]> 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
