About Go, D module naming

[Martin Nowak]

On 12/24/12 06:20, Martin Nowak wrote:
> On 12/23/12 03:35, Walter Bright wrote:
>> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>>> I think this is a fallacious argument because it concludes that apples
>>> should be
>>> peeled because oranges should.
>>
>> Given, in C++:
>>
>> struct S
>> {
>>    public:
>>       void foo(int);
>>    private:
>>       void foo(float);
>> }
>>
>> void bar()
>> {
>>      S s;
>>      s.foo(1.0f);
>> }
>>
>> This is an error in C++:
>
> Yeah, and it must stay one for D overload sets too.
> In my pull request I always used the most accessible protection for the
> visibility of an overload set without removing the access check after
> overload resolution.
>
> http://dlang.org/hijack.html
> https://github.com/D-Programming-Language/dmd/pull/739
>
Let me clarify the HideModuleMembers pull request.

Symbols with private protection are hidden when searching through 
imported modules.
Symbols with package protection are hidden when searching through 
imported modules from a different package.
The visibility of an overload set is determined by it's most visible member.
Protection does NOT alter overload resolution, i.e. matching within a 
visible overload set.
Members of classes and structs are always visible.

This mainly fixes #1238, i.e. name collisions in non static imports.
http://d.puremagic.com/issues/show_bug.cgi?id=1238