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
