Shadowing of module global TLS variables is not an error
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
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
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
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
More information about the Digitalmars-d