Shadowing of module global TLS variables is not an error

Walter Bright newshound2 at digitalmars.com
Sun Aug 16 23:34:44 UTC 2020


On 8/14/2020 5:51 AM, Steven Schveighoffer wrote:
> On 8/14/20 4:58 AM, Per Nordlöw wrote:
>> Shouldn't this code give a shadowing error?
>>
>> int x;                          // global?
>>
>> void test() @safe nothrow @nogc
>> {
>>      int x = x;                  // shouldn't this give a shadowing warning?
>> }
>>
> 
> I don't know if this is a hard-fast rule, but my view of the shadowing error is 
> that if you can access the variable, it's not shadowing.
> You can access the global via .x

It's a reasonable way to put it.

More to Per's query, the current behavior is not an accident nor a bug, it is 
deliberate.

It came about because in my long experience coding, I had repeated bugs due to 
shadowing of locals. It was difficult to tell, for longer functions, if a 
variable had already been declared. Even when done correctly, shadowing 
declarations made function code hard to understand. It made refactoring code 
harder than it needed to be. It made declaring new variables in nested scopes a 
problem because a reference to the outer name may go unnoticed, and a weird bug 
introduced.

Some judgements about why shadowing of globals is allowed:

1. It's just a bad idea in general to name globals with short names, and locals 
with long names. `x` should never be a global name. By following conventional 
coding practice, this should never be a problem.

2. It's just a bad idea in general to have many global variable declarations.

3. Having existing function declarations prevent changes to global names seems 
backwards.

4. I've never seen a bug from shadowing a global variable.

5. Anti-shadowing was a new concept at the time, and I decided to be a bit 
modest with it.

Overall, experience shows the proscription of shadowing has been a resounding 
success.


More information about the Digitalmars-d mailing list