public aliases to private/package symbols

[Timon Gehr]

On 01/25/2012 01:59 AM, Peter Alexander wrote:
> On Wednesday, 25 January 2012 at 00:08:25 UTC, Timon Gehr wrote:
>> Accessibility-raising aliases are trivially safe, because the alias
>> declaration must have access to the aliased symbol.
>
> You are probably right about not introducing holes, but I can imagine
> this getting tricky, and perhaps confusing in some cases. Here are some
> off the top of my head.
>
> module A;
> private class Foo {}
> public alias Foo Bar;
>
> In other modules that import A:
>
> Bar b = new typeof(b)(); // typeof(b) is Foo. Is this allowed?
>
> T foo(T)(T x) { return new T(); }
> Bar b;
> b = foo(b); // T is deduced to Foo, should this work?
>
> Bar b = new Bar();
> mixin("b = new " ~ typeof(b).stringof ~ "();"); // This fails, the
> string is "Foo"
>
>
> Just thinking about this has made me change my position. Accessibility
> raising aliases should not be allowed. It's a minefield.

That is a valid counter-argument. While I am sure these issues could be 
sorted out, it would probably amount to over-engineering. This is 
basically the only useful use case worth considering:

private template Tmpl(T){...}
public alias Tmpl!int foo;

Tmpl and Tmpl!int are two _distinct symbols_, and there is no dedicated 
syntax to make just one of them accessible.

Therefore, this use case could be allowed as a special case: Explicit 
use of Tmpl from another module would be forbidden, but the instance 
Tmpl!int would be public under the name foo. (While explicitly 
instantiating Tmpl!int would fail, because Tmpl is not accessible (or 
ideally not visible).)

There would be no public/private aliasing, and therefore all the issues 
you mentioned would not exist in this case.