public aliases to private/package symbols

[Timon Gehr]

On 01/24/2012 07:52 PM, Jonathan M Davis wrote:
> 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?
>

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.

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

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