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

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