Should protection attributes disambiguate?

[Jonathan M Davis]

On 2011-06-20 15:43, Nick Sabalausky wrote:
> "Nick Sabalausky" <a at a.a> wrote in message
> news:itoiji$2hsk$1 at digitalmars.com...
> 
> > "Peter Alexander" <peter.alexander.au at gmail.com> wrote in message
> > news:itog87$2ed9$1 at digitalmars.com...
> > 
> >> I'm working on a fix to
> >> http://d.puremagic.com/issues/show_bug.cgi?id=6180
> >> 
> >> Essentially the problem boils down to:
> >> 
> >> - Module A has a private symbol named x
> >> - Module B has a public symbol named x
> >> - Module C imports A and B and tries to use x unqualified
> >> 
> >> Should the fact that B.x is public and A.x is private disambiguate the
> >> usage in module C to use B.x, or is that still an ambiguous unqualified
> >> usage of variable x that requires manual qualification/disambiguation?
> > 
> > If something's private, it's supposed to be an "internal-only" sort of
> > thing. Private. Outside its own module, it shouldn't even be visibile and
> > it's existence shouldn't have any effect. So I'd say unqualfied use of x
> > inside C should definitely be allowed and resolve to B.x.
> 
> I'd add that IMO, to do otherwise would break encapsulation (or at least
> put a big ugly dent in it).

Well, except that access modifiers are _access_ modifiers. They indicate 
whether you can _use_ a particular symbol, not whether you can see it. So, the 
fact that a symbol is private has _zero_ affect on whether other modules can 
see it.

That being said, the only situation that I can think of where it would cause a 
problem for private to be used as part part of the disambiguation process 
would be if you're trying to use a symbol which is private (not realizing that 
it's private) and end up using a symbol with the same name which you actually 
can access, and it manages to compile, and you end up using a symbol other 
than the one that you intended. Now, I wouldn't expect that to be a big 
problem - particularly since in most cases, the symbols likely wouldn't be 
able to be used the same and compile - but it is at least theoretically a 
concern.

Personally, I think that the gain in making it so that the compiler can assume 
that a private symbol doesn't enter into overload sets or whatnot would far 
outweigh that one, particular problem.

- Jonathan M Davis