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_at_[hidden]> 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_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]> 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
>
>

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