Shadowing of members

[deadalnix]

On Thursday, 10 January 2013 at 08:35:14 UTC, Jonathan M Davis 
wrote:
> On Thursday, January 10, 2013 09:07:49 deadalnix wrote:
>> Consider also that this is yet another inconsistency, which is 
>> a
>> bad thing in itself.
>
> What inconsistency? There's no inconsistency here. Is it that 
> you think that
> the fact that the local variable shadows the member variable is 
> an
> inconsistency? The _only_ case where variable shadowing is 
> illegal is when one
> local variable shadows another local variable, and that's 
> because you can't
> access the shadowed variable when that happens. In all other 
> cases, you can
> access the shadowed variable (be it through the this 
> pointer/reference or
> through . or by using the full import path to the variable). 
> So, if anything
> is inconsistent, it's the fact that shadowing one local 
> variable with another
> is illegal. It's legal with everything else and quite easy to 
> work around when
> it happens.
>

How many time did you find yourself in a position of where you 
say to yourself "how no, I can't access that variable anymore 
because it is shadowed !".

And, if this is really the reason, why is this forbidden ?

void foo() {
     {
         int bar;
     }
     {
         float bar;
     }
}

> Or are you arguing that something else here is an inconsistent? 
> Because I
> don't see it, and I don't know what else from this thread that 
> you could
> possibly be referring to.
>

It is sometime allowed to shadow declaration and sometime not. 
This is not very consistent. Inconsistency come always at a cost, 
so the benefit must be very real to create one.