public aliases to private/package symbols

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:jfo1i0$18rq$1 at digitalmars.com...
> "Timon Gehr" <timon.gehr at gmx.ch> wrote in message 
> news:jfnsne$10re$1 at digitalmars.com...
>> On 01/25/2012 03:56 AM, Nick Sabalausky wrote:
>>>
>>> There's no need for special cases. Just don't go de-aliasing symbols. 
>>> That
>>> takes care of everything.
>>>
>>
>> It does not.
>>
>> private class A{
>>     static A factory();
>> }
>>
>> public alias A B;
>>
>> What is typeof(B.factory()) ?
>>
>
> That's not a problem that's specific to alias. It's symptomatic of a more 
> general access issue (instances of private types exposed in a public 
> interface) that is *not* solved by prohibiting access-expanding aliases:
>
> private class A{
>    static A factory();
> }
>
> public class B{
>    A foo() { return A.factory(); }
> }
>
> In another module:
>
> typeof((new B()).foo()) // What should happen?
>
> If "public alias A B" must be banned due to tough accessibility questions, 
> then so must "class B". Point is, it's not an issue specific to alias.
>

Of course, my position isn't purely defensive. Here's why access-expanding 
aliases cannot be prohibited:

private struct DirtyFooImpl(int i){}

template Foo
{
    alias DirtyFooImpl!5 Foo;
}

That's a simplistic example of very common, very useful idiom. Note that 
there's no way to do that without access-expanding aliases. If 
access-expanding aliases are banned, then this idiom must go away too. Then, 
a big chunk of my Goldie project and no doubt many other projects suddenly 
break, and the only way around it is to publically expose things that are 
*not supposed to be exposed*, and congrats, now we've just stepped back in 
time to pre-encapsulation-enforcement days.