Should alias expand visibility?

[Tomek Sowiński]

Steven Schveighoffer wrote:

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

Of course I see it. I wouldn't ask if I didn't ;)

If it doesn't make sense, the compiler should help by e.g. failing with 
"can't declare an alias more visible than the aliased symbol".

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

byColumns and byRows *are* public (default for structs). But it won't work 
now because byPermutation(Ortho)Dim are private.

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

Again, if it's no good, ban it to make things clear.

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

Nick answered that. What worries me more is whether bar() should trigger the 
class invariant, whether bar should be exposed to exe/dll, etc. If so, this 
would mean the very presence of an alias can alter the code generation, 
which seems against alias'es spirit of being just a shortcut to a symbol. My 
opinion is shifting towards banning public->private aliases because of 
this...


Tomek