On Tue, 21 Jun 2011 06:04:28 +0300, Jonathan M Davis <[email protected]>
wrote:
It matters for stuff like NVI (Non-Virtual Inheritance). In that
particular
case, you overload a private function but you can't call it. You couldn't
overload it if you couldn't see it. So, there _are_ cases where it
matters,
and it _is_ an important distinction. It's just that it matters
infrequently
enough that most people don't realize that there is such a distinction.
But
distinction or not, I don't see why we couldn't just make it so that any
attempt to use a symbol where the clashing symbol can't be used anyway
just
doesn't clash by ignoring the private symbol in such cases.
- Jonathan M Davis
Good example, is it only this or are there any others?
I am asking because i think this particular use case doesn't justify
visibility but not access.
If i got it right, we are talking about something like this:
module base1;
private import base;
struct base1 : base {
}
module base2;
import base1;
struct base2 : base1 {
}
Shouldn't compiler just issue an error whenever base1 accessed outside of
the module it belongs?
With its current state, it just encourages bad design as far as i can see.
First of all inheriting from a class/interface/struct that is imported
private implies this new class is going to be an implementation detail,
hidden from user. If it wasn't intended, why would you import it private?
