On 12 Aug 2026 12:32, Simon Schröder via Std-Proposals wrote:
> I think a better reason to disallow reusing variable names is
> maintainability. Suppose we have a long function (I know we shouldn't,
> but everybody has at least one of these) with a variable declaration at
> the top and its last use at the bottom. Now, if I redefine the variable
> with the same name but a new type somewhere in the middle (I thought it
> wouldn't be used below this point), suddenly my program might do
> something totally unexpected (it's a logic bug). However, if I just
> forget/poison/redact the variable name I get a compiler error. Getting a
> compiler error is acceptable, silently accepting different behavior is not.

I'm not sure I buy this use case.

First, if the example is that a programmer forgets (no pun intended) or
misses that a variable that is declared at the beginning of this long
function is used at the end and clobbers it in the middle then he might
as well forget to "redact" it in the middle. And actually, he couldn't
redact it as he would not be able to use the variable in the end, so
this example doesn't work.

If the example is that the variable that is declared and used at the
beginning of the function is then being redeclared later. That would be
a compile-time error currently, so no redacting needed. Furthermore,
redacting doesn't help, as it would prohibit using this name again -
presumably, until the end of the function? Or scope? Or TU? Either way,
the compilation error is not fixed and the user still has to invent a
new name for the variable. And also it isn't clear who is supposed to do
the redacting and what for (is it the one who wrote the original code
with the variable at the beginning of the function or the one who is
adding the second variable later - none of these programmers have a
reason to redact anything).

Furthermore, I have reservations about usefulness of this redact thing,
depending on the scope of its effect, especially given that it is
supposed to be permanent, as opposed to simply removing the redacted
name from lookup. There's a lot of code that we use in our programs that
isn't written by us. If I redact a name somewhere in my global header
(which is one of the presented use cases for this feature, e.g. to
remove the undesired parts of the standard library from use in the
project), I might be breaking third party libraries that happen to be
included after that my global header. And yes, this can easily happen
even if you try to manage include order manually, which is a whole
another headache. If I instantiate a function or class template after
the name was redacted, and the template references the name in a
dependent context, does that constitute an error? If I expand a macro
and the expansion uses the redacted name, surely that constitutes an
error, doesn't it? If the redacted name is a namespace, is it possible
to reopen the namespace e.g. to add more to it? Because if not,
redacting e.g. namespace detail, as was suggested by someone, becomes
unusable, if the namespace is used by a library spanning multiple
headers (because where would you redact it?). And the problem becomes
more likely to occur the wider the scope of the effect of this redacting.

I think, the OP needs to reconsider the intended use case of this
feature, accounting for the fact that not all of the compiler code may
be under the control of the programmer. If the intended use case is
limited to just avoiding name clashes within the function scope, I
think, a way of "undeclaring" or "shadowing" a variable declaration
after a certain point (with the ability to reuse the variable name)
would be more appropriate and useful. If the intended use case is to
affect some more global TU state, then the feature becomes increasingly
more controversial and less useful, IMO.