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]> on behalf of Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, August 23, 2026 5:00:17 PM
To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
Cc: Jonathan Grant <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]> 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]> 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]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals