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
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


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