Should alias expand visibility?

[Steven Schveighoffer]

On Tue, 27 Jul 2010 01:01:44 -0400, Nick Sabalausky <a at a.a> wrote:

> "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(); }

But the compiler can understand that.  I think when you use an alias, the  
compiler treats it like you typed the other name.  This can be seen in  
ddoc, when you use an aliased type, ddoc shows the type you aliased, not  
the type you wrote.  I think this would require a huge change to the  
compiler, for very little benefit.

And usually there are reasons you want to use private functions.  This  
doesn't seem to have a reason.  Why not just call funcA funcB?  There are  
better ways to rename functions.

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

If you want it exposed, why not make funcA public?  These simple examples  
are not compelling.

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

And why would you have one of those references be private?  I don't  
understand that aspect of it.

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

Alias is good for renaming public functions without overhead.  But  
renaming private functions doesn't make any sense, you are the only one  
calling them, why do you need to name them differently?  If it should be a  
public function named x, why does it also need to be a private function  
named y?

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

I withdraw that argument ;)  I think the better argument is that it serves  
no purpose to have a private alias to a public function.  You can just as  
easily call the public function.

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

(Yes, I did mean B : A, I always forget that!)

So private int foo is now a virtual function?  That seems very  
counter-intuitive.

-Steve