About Go, D module naming

[Martin Nowak]

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