Re: RFC: Enabling -Wshadow, by default?

Am Montag, 5. Januar 2026, 10:08:41 Mitteleuropäische Normalzeit schrieb 
Sune Vuorela:
> On 2025-12-29, Friedrich W. H. Kossebau <[email protected]> wrote:
> > --- 8< ---
> > 
> > Now, fixing those warnings one finds there are some cases where the
> > shadowing might not really be a critical issue. E.g. names of local 
helper
> > variables which are later reused in another deeper scope, with little
> > chance to get this wrong:
> > --- 8< ---
> > 
> >     [...]
> >     auto it = something();
> >     if (it)
> >     [...]
> >     for (...) {
> >     
> >        [...]
> >        auto it = somethingelse();
> >        if (it)
> >        [...]
> >     
> >     }
> > 
> > --- 8< ---

Anyone? I have seen meanwhile related changes, which were simply using 
alternative names in such cases (e.g. index vs. idx). Myself not convinced 
these changes improved things in summary...

> cppcheck also have warnings for that.
> 
> There is also the
> 
> QString Foo::name() const {
>    return {};
> }
> 
> void Foo::someFunction() {
>     QString name = name();
>     ....
> }
> 
> That we have in quite many places (cppcheck also warns by default on
> these)

Though what is the motivation of this kind of function-shadowing-by-variable 
warning? What risks are there when missing out the same name? Given the type 
is different here almost always?

A pattern I have seen often in code is using the same variable name for 
caching the result of some more expensive getter call for a property, which 
has made totally sense when reading the code as human in the given context. 
And cannot remember bugs related to any shadowing here:
--- 8< ---
    void Foo::someFunction()
    {
        // cache result of expensive to estimate property
        const QString name = this->name();
        // do stuff referencing "name" property value multiple times:
        // [...]
    }
--- 8< ---

So, what motivates people to act on this type of warning cppcheck emits?

And what would be the naming pattern to use here instead, which adds more 
value by the risks avoided over the cost of more explicit/cumbersome names?

Cheers
Friedrich