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

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

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