Should alias expand visibility?

[Steven Schveighoffer]

On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowiński <just at ask.me> wrote:

> W dniu 26.07.2010 22:56, Nick Sabalausky pisze:
>> "Steven Schveighoffer"<schveiguy at yahoo.com>  wrote in message
>>> Your simple example doesn't make any sense.  Why wouldn't you just make
>>> foo public?  If it's publicly accessible through an alias, it's  
>>> publicly
>>> accessible.  I don't buy the "too hard to understand" argument.  Just
>>> don't document the "private" members :)
>>>
>>> IMO, protection attributes applied to an alias make no sense  
>>> whatsoever.
>>> I don't think the above code should compile, except dmd accepts lots of
>>> noop attributes...
>>>
>>
>> I disagree. I think it's perfectly rational. Perhaps a better example  
>> than
>> the above:
>>
>> private void foo_implA() {...}
>> private void foo_implB() {...}
>> private void bar_implA() {...}
>>
>> static if( isDerpDerpDerp )
>> {
>>      public alias foo_implA foo;
>>      public alias bar_implA bar;
>> }
>> else
>> {
>>      public alias foo_implB foo;
>>
>>      // If isDerpDerpDerp isn't true, then 'bar' is logically equivilent
>>      // to the faster foo_implB, so just use that:
>>      public alias foo_implB bar;
>> }
>>
>> I see no reason to disallow something like that.

But do you see the problem?  The *alias* is public, but the *function* is  
private.  To me it looks like, "here's a public name for my private  
function" I don't think it makes the function public, just the name, which  
doesn't make any sense.  IMO, all three impl should be public if you want  
them to be callable.


>
> Yes, or a real-life example (sorry for quoting myself, but seems  
> Steven's joke overshadowed it :) ):
>
> struct PermutationMatrixExpr(Permutation permut) {
>      static if (permut == Permutation.RowWise) {
>          alias byPermutationDim byRows;
>          alias byPermutationOrthoDim byColumns;
>      } else {
>          alias byPermutationDim byColumns;
>          alias byPermutationOrthoDim byRows;
>      }
>
> private:
>
> // Definitions for byPermutationDim & byPermutationOrthoDim
>
> }

Again, I don't see the problem in making byColumns and byRows public.  If  
that's not an option, you can always wrap, and rely on inlining (well,  
hopefully when inlining is good enough).  I just don't see this as being  
something that's of enough use to justify a compiler change.

>
>>> Let me draw a parallel example:
>>>
>>> int x;
>>> const alias x y;  // I want y to be a const view of x
>>>
>>> Does this make any sense?
>>>
>>
>> Just because one particular attribute doesn't make sence doesn't mean  
>> they
>> all don't make sence.

But a public alias to a private function to me is worthless.  The function  
must be kept private, because that was the intention of the author.

> Can anyone give a good counter-example when a public alias of a  
> non-public symbol is evil?

How about this one:

class A
{
    private int foo() {};
    public alias foo bar;
}

class B
{
    public int bar() {};
}

A a = new B;
a.bar(); // What should this call?

-Steve