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
