"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.vggugam1eav...@localhost.localdomain...
> On Mon, 26 Jul 2010 15:08:32 -0400, Tomek Sowinski <j...@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.
