The point is: the inner code may not be aware of what the outer code does or names, and it should not need to (exactly because it is local).

If some fool uses a bad name for a global variable (it could be from a third party, which makes it more difficult to request changes), my code should not be affected. Even if it is from the same organization, people still can say: "Yes, I see it is a bad name. However, since it is already published, I need to keep backward compatibility and will not change it." Or, slightly better, "I need to deprecate it first, and change it in a year."

Not every developer is disciplined. I have seen enough identifiers that are neither prefixed nor in an appropriate namespace. I do not feel like avoiding all such polluted names.

On Mon, 24 Aug 2026 at 16:37, Tiago Freire <tmiguelf@hotmail.com> wrote:

> 1. A local variable in a function happens to have the same name as a global variable, and thus shadows the global variable.

 

Maybe name it something else more specific clearly indicating it is a global?

 

 

> 2. A lambda expression happens to use the same parameter name or local variable name as a variable name in the enclosing function.

 

It’s in the enclosing function; it’s precisely the kind of thing that invites confusion. Just name it something different?

 

 

> And I do not like the `-Wshadow` warning.

 

I do. It has avoided bugs in my code. It can cause problems, people created that warning for a reason.

 

 

If you say “I want this because of access control” then I get. If you say “I want this because I want to shadow variables easier” then I think that sounds like a bad idea, because I think shadowing is a bad practice.

 

One identifier should unequivocally refer to one object, I think it is ok to change what you can access in that object at certain times, but not change to a different object entirely. When you change the object entirely, that’s exactly where things start to get confusing, and hard to follow, and that’s where you get bugs.

 

 

From: Yongwei Wu <wuyongwei@gmail.com>
Sent: Monday, August 24, 2026 08:39
To: std-proposals@lists.isocpp.org
Cc: Tiago Freire <tmiguelf@hotmail.com>
Subject: Re: [std-proposals] Forget forget let's redact

 

Shadowing is not normally intentional. I agree intentional shadowing is weird, but consider the following scenarios:

 

1. A local variable in a function happens to have the same name as a global variable, and thus shadows the global variable.

2. A lambda expression happens to use the same parameter name or local variable name as a variable name in the enclosing function.

 

I would argue that renaming the inner variable due to collision with an outer variable is unnecessary. And I do not like the `-Wshadow` warning.

 

By the same logic, `redact` should not interfere with a variable declaration in another scope.

 

Except for the fact that people probably do not want a new keyword, I do not like the function form of `redact`, which is deceptive. `redact` is not a function call, but something more like a variable declaration. Following declaration rules would make it simple to understand and reason with.

 

By the way, I find `redact` reasonable, but cannot find a valid use for `unredact`.

 

On Mon, 24 Aug 2026 at 05:27, Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

I personally never thought that variable shadowing was ever a good practice.

Having the same variable name serve different purposes in the same function is just asking for confusion. The feature should control access, not be an enabler for confusing code practices.

 

 


From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Jonathan Grant via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Sunday, August 23, 2026 5:00:17 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Jonathan Grant <jgrantonline@gmail.com>
Subject: Re: [std-proposals] Forget forget let's redact

 



On 23/08/2026 06:52, Simon Schröder via Std-Proposals wrote:
>
>
>> On Aug 23, 2026, at 1:24
AM, Henry Skoglund via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>>
>>
On 2026-08-23 01:12, Ville Voutilainen wrote:
>>> On Sun, 23 Aug 2026 at 00:53, Henry Skoglund via Std-Proposals
>>> <std-proposals@lists.isocpp.org> wrote:
>>>>> For ergonomics, I'd prefer an inferface where redact returns
>>>>> std::remove_reference_t<T>&& like std::move and unredact returns T& so
>>>>> that one could do:
>>>> Thank you, pretty nice idea. As long as std::unredact() follows the same
>>>> playrules as std::redact():
>>> It's a nice idea, yes. Ted is completely correct that it's a nice
>>> idea, and could be useful for some cases.
>>>
>>> I'm not even against Ted's idea. I just want to suggest that we keep in mind
>>>
>>> return -ENOTENOUGHBANGFORTHEBUCKESPECIALLYFORTHECOMPLEXITY;
>>>
>>> I seriously don't have a strong opposing viewpoint here. Being able to
>>> poison name lookup seems handy.
>>> Being able to poison the lookup and then unpoison it.. ..seems..
>>> ..questionable. The former I could explain.
>>> The latter.. ..I would struggle  to explain.
>> Yes let's agree std::redact() is the main race horse to bet on here, and a std::unredact() could be a future, separate proposal.
>
> In the beginning of this discussion, people heard std::redact and immediately thought: Can I then reuse the variable name? This clashes with std::unredact. In the most extreme case we could allow both, but only either one of them can be used; i.e. if I reuse the variable name I can no longer unredact the “shadowed” variable.


Well, we can re-use the variable name in a separate scope. std::redact(x) makes it clear that the earlier x cannot be used.

int x = 10;
std::redact(x);

{
    int x = 11;
    std::cout << x << "\n";
}

// Compiler diagnostic. Makes a programmer think
std::cout << x << "\n";

However, for human reasoning, isn't it safer to use smaller functions, and avoid re-using variable names? Smaller possible control-flow paths, simpler states. Making lifetime boundaries simpler, ownership etc. Reducing accidental confusion about which value is being used.

gcc, clang already warn with -Wshadow
How would std::redact work with this, presumably no compiler diagnostic if std::redact(x); ?

https://godbolt.org/z/chfqfffM7

Regards
Jonathan


--
Yongwei Wu
URL: http://wyw.dcweb.cn/