"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message news:op.vgh50ulqeav...@localhost.localdomain... > >> private void funcA() {} >> public void funcB() >> { return funcA(); } >> >> In that, funcA is supposed to be private, but funcB exposes it...But so >> what? If you didn't want it exposed, you wouldn't have made funcB public. > > If you want it exposed, why not make funcA public? These simple examples > are not compelling. >
So you think that the funcA/funcB combination above should be disallowed? That's the point I was making. If you feel that should be disallowed, then we just simply disagree on a very fundamental level. If you don't think that should be disallowed then I think you're viewpoint is self-contradictory. As for the usefulness of providing public access to a private symbol regardless of whether it's via alias or forwarding, see the "static if" examples both Tomek and I provided. And as for why not keep all of those public, there are perfectly legitimate real-world reasons to not want to do that. The simplest probably being to keep a public interface free of unnecessary clutter. > > (Yes, I did mean B : A, I always forget that!) > > So private int foo is now a virtual function? That seems very > counter-intuitive. > I'd consider throwing away polymorphism just because one symbol was created with an alias to be far more counter-intuitive. And I would also consider disallowing a perfectly logical combination of visibility attributes and alias to be more counter-intuitive.
