Warning on template parameter identifier shadowing?

[Steven Schveighoffer]

On 8/5/20 12:35 PM, Paul Backus wrote:
> On Wednesday, 5 August 2020 at 16:22:48 UTC, Steven Schveighoffer wrote:
>> On 8/5/20 12:10 PM, Paul Backus wrote:
>>>
>>> Not a fan. There are cases where I've done this intentionally--not 
>>> with eponymous template members, but with private helper templates:
>>>
>>> template foo(T) {
>>>      enum helper(T) = ...; // error?
>>>      void foo(T i) {
>>>          static if (helper!T) ...;
>>>          else ...;
>>>      }
>>> }
>>
>> I've intentionally done that, and even though it worked, rewrote the 
>> template parameter names because it's confusing to read.
>>
>> It would have to be a long deprecation cycle.
>>
>> I would be in favor of the change.
>>
> 
> "Confusing to read" does not justify a compiler warning. The compiler 
> accepts lots of code that's confusing to read.

That's not a justification, just my personal experience. I read my code 
again and think, "wait, what T am I talking about? I'll just change it 
to U."

For the same reason, I don't like to name inner struct members the same 
as any function variables, even though that's allowed.

In essence, this is no different than erroring on shadowing of function 
variables, which could also be allowed, but saves a lot of trouble. You 
can look at it more as a "hey D, you have this position on variable 
names, but not on template parameter names, why the inconsistency?"

Note that I think it purely should be for nested template *parameters*, 
not for other names.

> (This would also interact very badly with string-based code generation, 
> since there's no reliable way to generate unique identifiers at compile 
> time.)
Somehow people cope with this for shadowed variable names just fine.

-Steve