"Timon Gehr" <[email protected]> wrote in message news:[email protected]... > 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.
