public aliases to private/package symbols

[Jonathan M Davis]

On Tuesday, January 24, 2012 18:58:45 Martin Nowak wrote:
> Should aliases be allowed to raise the accessibility of a symbol?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4533

Having an alias make a symbol more accessible makes no sense to me IMHO. If 
you're talking about private -> public, then why is the symbol private in the 
first place, since you're then in the same module making the same thing both 
public and private - just with different names. And if you really want one of 
the two symbols private and the other public, why not just switch them and use 
a private alias? The only time that that wouldn't work that I can think of 
would be a templated type, in which case does it really hurt to have the type 
be public anyway?

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.

So, I definitely think that an alias should not allow a symbol to become _more_ 
accessible.

> 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.

- Jonathan M Davis