public aliases to private/package symbols

[Timon Gehr]

On 01/25/2012 12:09 AM, Peter Alexander wrote:
> On Tuesday, 24 January 2012 at 22:26:37 UTC, Nick Sabalausky wrote:
>> This whole issue is literally *NO* different from "Should a public
>> pointer/reference be allowed to point to private data?" or "Should a
>> public function be allowed to expose a private one?" The answer is:
>> "Obviously yes".
>
> Things can be obvious in different ways.
>
> For example, one could argue that it's also obvious that an alias should
> behave exactly the same as the thing it aliases. Allowing aliases to
> change protection would break that.

The accessibility of something is not part of its behavior.

>
> For the record, I agree that the answer should be "yes", but it's not a
> decision that should be made rashly. If we aren't careful, we could
> introduce a hole in the protection system in a non-obvious way. C++'s
> protection system has a non-obvious hole:
> http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html
>

Non-obvious? Perfectly obvious: Access checking rules do not apply to 
names in explicit template instantiations. It is an explicit rule that 
states access checking is subverted.

>
> Again, I agree, but what's obvious isn't always true, so it needs to be
> considered in depth.

Accessibility-raising aliases are trivially safe, because the alias 
declaration must have access to the aliased symbol.