Jonathan M Davis <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #3 from Jonathan M Davis <> 2011-06-25 10:06:39 
PDT ---
In general, if a function is visible, then the compiler knows about it. If it
weren't visible, then the compiler wouldn't really see it when a module
imported the module that it's in. If it's visible but inaccessible, then the
compiler can see it, but it won't allow you to use it. So, for instance, if you
tried to use a private function, then it could complain about the function
being private, so you can't use it. But if it were not visible, then the
compiler would have to complain that you were trying to use a symbol that it
didn't know about.

Private symbols are perfectly visibile. They're just not accessible. All that
public, package, protected, and private affect is accessibility, not
visibility. They're _access_ modifiers. And overload resolution occurs _before_
accessibility is checked, which is part of the reason that you've been running
into issues with private stuff conflicting with public stuff.

You can check out this explanation with regards to C++ (which is essentially
the same):

Also, look into NVI (Non-Virtual Inheritance). Herb Sutter discusses it in C++

Assuming that private functions are overridable (which according to TDPL, they
should be, but they aren't currently in D), then derived classes can override
private functions without being able to call them. Andrei discusses it starting
at page 213 of TDPL. That wouldn't be possible if private functions weren't

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to