About Go, D module naming

[Rob T]

On Sunday, 23 December 2012 at 02:35:46 UTC, 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++.)
>
> Why does this never come up on peoples' complaints about C++? I 
> spent some time googling it, and came up with nothing.
>
> I don't think it can be dismissed as fallacious unless the 
> why's have a rationale.

I don't see how that example can be compared with the issue 
Jonathan is raising.

If I understood the issue correctly, the visibility of all module 
members are global in scope, and that's why two modules may have 
names that clash. What people want are private module members not 
to be visible outside of the module.

We're speaking about D rather than C++, but I can give you an 
example of how a somewhat analogous situation can cause serious 
problems in C++.

When using dlopen() with the RTLD_GLOBAL flag, it causes all 
symbols from the loaded library to become visible to subsequently 
loaded libraries. When there are symbol clashes, instead of an 
error, one of the symbols is used rather than the other, causing 
the application to behave in unexpected ways.

For dlopen() the default behavior is RTLD_LOCAL, which makes all 
symbols from loaded libs private to their respective libs. This 
is the default behavior to ensure predictable execution 
behaviors, and it's the same default behavior that modules should 
have.

--rt