public aliases to private/package symbols

[Nick Sabalausky]

"Timon Gehr" <timon.gehr at gmx.ch> wrote in message 
news:jfnlpu$k0p$1 at digitalmars.com...
> 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.
>

There's no need for special cases. Just don't go de-aliasing symbols. That 
takes care of everything.