On Mon, 02 Apr 2012 19:10:01 +0200, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it. Thus it user
can't depend on private members being there, which is a good thing.
If I read it right, the technique you present allows user code to depend
on private functions being there.
I argue that we shouldn't even provide a _possibility_ for external
stuff to depend on private members.
Same argument in limited scope goes for protected.
As it stands, private has _no_ effect on symbol visibility. All it
affects is
symbol accessibility. For instance, if you create a private alias in a
module,
it affects every module that imports your module, or if you create a
function
which causes an overload conflict, it creates an overload conflict
regardless of
whether it's private or not. C++ is the same way. Access modifiers are
just
that, _access_ modifieres. They _only_ affect accessibility, not
visibility.
Access modification really makes sense for nested scopes.
After all you can have access to a value of a protected type.
In this case changing the visibility could lead to accidental
mismatches. This behavior is taken from C++ and it makes sense.
Due to the .h/.cpp separation you'll also have most of the
implementation symbols invisible. That's where the C++ model
doesn't really map to D if 'import everything' remains the default.
