Should alias expand visibility?

Nick Sabalausky a at a.a
Mon Jul 26 13:56:50 PDT 2010


"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.vggugam1eav7ka at localhost.localdomain...
> On Mon, 26 Jul 2010 15:08:32 -0400, Tomek Sowinski <just at ask.me> wrote:
>
>> Nick Sabalausky wrote:
>>
>>>> Sorry you had to go through that.  My post was an attempt at dry humor 
>>>> ;)
>>>>
>>>> -Steve
>>>
>>> Heh, now I get it too. Good one :)
>>
>> Now me too:) But let's stay on the path:
>>
>> private void foo();
>> public alias foo goo;
>>
>> We gotta do something about this WTF. Either goo should be perfectly 
>> usable
>> or the compiler shouldn't allow visibility expanding aliases. Which'd you
>> pick?
>
> Serious now:
>
> 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.

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




More information about the Digitalmars-d mailing list