Should alias expand visibility?

[Nick Sabalausky]

"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.vgg66qezeav7ka at localhost.localdomain...
> On Mon, 26 Jul 2010 17:42:53 -0400, Tomek Sowinski <just at ask.me> wrote:
>
>> W dniu 26.07.2010 22:56, Nick Sabalausky pisze:
>>>
>>> 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.
>

I'm not sure that's a valid argument, because the same argument could be 
made for function forwarding:

private void funcA() {}
public void funcB()
{  return funcA(); }

In that, funcA is supposed to be private, but funcB exposes it...But so 
what? If you didn't want it exposed, you wouldn't have made funcB public. 
Likewise, If I say "public alias xxx yyy;" I'm saying that I *do* want 
expose xxx publically through the name yyy.

The thing is: "private" has never meant "this can never be accessed from the 
outside". It has always just simply meant "this can never be accessed from 
the outside *through this particular member/identifier/whatever*".

And it doesn't even have to be function forwarding, it could just be two 
references to the same object.


>
> 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.
>

Hmm, again I see it differently: If that's the effect I want, why should I 
have to go through the bother wrapping and inlining when the language 
already has "alias". Besides, your argument here could be applied to the 
idea of removing many other uses of alias, if not removing alias entirely.


>
> 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.
>

I think my function forwarding argument above serves as a strong 
counter-argument to this.


>> 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?
>

Assuming you meant "class B : A", I'd say that should have identical 
semantics to (That is, of course, identical semantics with the obvious 
exception being the result of "&A.foo == &A.bar"):

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

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

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

Which would be a compile-time error because B is overriding A.bar without 
using the "override" keyword. If you added "override" to B.bar, then B.bar 
should be called.