About Go, D module naming

[Timon Gehr]

On 12/23/2012 03:35 AM, 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++:
>
> foo.cpp:6: error: âvoid S::foo(float)â is private
>
> (I used g++ so nobody would complain this is a defect in dmc++.)
>

structs and classes are utterly irrelevant at this point of the discussion.

Are you aware what the problem Andrei was referring to is?

> Why does this never come up on peoples' complaints about C++? I spent
> some time googling it, and came up with nothing.
>

This is not the primary problem, because it can be avoided by not 
overloading public vs. private against each other.

This is the problem:

module a;
private void foo(){}

module b;
public void foo(){}

module c;
import a,b;
void main() {
     foo(); // error: conflict
}

The error message is misleading. There is no conflict. Nor is there a 
problem. The error is completely spurious.

> I don't think it can be dismissed as fallacious unless the why's have a
> rationale.
>

Modularity is achieved in rather ad-hoc ways in C++. Why do you think 
C++ is relevant?