Should protection attributes disambiguate?

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.1058.1308610718.14074.digitalmars-d at puremagic.com...
> 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.
>

Technically, maybe, but there's not much point in seeing it if you can't 
access 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.
>

Yea, certainly true. But you can have problems the other way too: A module 
introduces a new private class/function/variable solely for it's own 
personal use, and it just happens to have the same name as a public member 
of some other module. So all the code that uses that public member ends up 
broken, just because the internal details of something else got changed.

So like you, I think the benefits of not letting private stuff participate 
in overload resolution are well worth the risk of that rare scenario you 
describe.

> 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.
>