> 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_at_[hidden]>
Sent: Monday, August 24, 2026 08:39
To: std-proposals_at_[hidden]
Cc: Tiago Freire <tmiguelf_at_[hidden]>
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_at_[hidden]<mailto:std-proposals_at_[hidden]>> 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_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> on behalf of Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Sunday, August 23, 2026 5:00:17 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Jonathan Grant <jgrantonline_at_[hidden]<mailto:jgrantonline_at_[hidden]>>
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_at_[hidden]<mailto:std-proposals_at_[hidden]>> 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_at_[hidden]<mailto:std-proposals_at_[hidden]>> 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
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


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