public aliases to private/package symbols

[Martin Nowak]

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