Yes, because the module cannot transparently change the implementation
of the aliased types if the template that provided the basis is public.
(If you ignore error messages.) I think private->public aliases make
sense and should be allowed.
I mostly agree with Jonathan, but that's a good argument.
The real problem though is protected->public. That makes it possible
for one
module to increase the access level of the symbol in another module.
That's
completely unacceptable IMHO. No module should have control over another
module's symbols' access level.
overrides can increase the access level from protected to public,
therefore I cannot see why aliases should not be allowed to do the same.
(protected is almost as public as public anyway. It is possible to
create a template that creates a type that behaves like its argument,
except that it raises the accessibility of all protected members to
public without using protected->public aliases.)
This currently gives me some headache while trying to straighten
protection checks.
It seems to be a special case to make templates more usable as the
instantiation
scope wouldn't actually allow you to access the type.
Without that hole you'd get C++ like shared_ptr with private destructor
errors.
So, I definitely think that an alias should not allow a symbol to
become _more_
accessible.
It has some sane applications and does not compromise information hiding
features in any way. There is no reason to ban such aliases.
http://d.puremagic.com/issues/show_bug.cgi?id=6013
Private aliase make a lot of sense to me as long as they actually hide
the
symbol. That would allow you to rename a symbol internally (e.g. using
it to
indicate that whenever you use indexOf without fully qualifiying it,
you mean
the one from std.algorithm, not the one from std.string) without
affecting any
modules that import that module. However, if it works how private
normally
works and just affects access level, not visibility, then it's utterly
pointless. And unfortunately, at present, that appears to be how it
works. So,
creating any aliases that aren't public seems like a _bad_ idea to me,
since
it will needlessly affect other modules. If private actually hid symbols
instead of just making them inaccessible though, it would be a
completely
different story.
It would be great if all private members were invisible to the outside
world. I don't think the inaccessible/invisible distinction has any
merits. (except maybe that it simplifies some DMD implementation
details.)
Yeah, especially sine private imports are already a visibility boundary.
