On 12/08/2026 15:40, Andrey Semashev via Std-Proposals wrote:
> On 12 Aug 2026 16:26, Simon Schröder wrote:
>>
>>
>> On Wed, Aug 12, 2026 at 12:55 PM Andrey Semashev via Std-Proposals <std-
>> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>>
>> 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.
>>
>> It's okay if he forgets to redact it in the middle. Redactions are for
>> your own safety in order to not continue using a variable.
>>
>> 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.
>>
>> That's the whole point: Redacting the variable is an error when it is
>> still used later. It is okay if during maintenance I wrongfully redact a
>> variable name because the compiler will tell me that it is an error.
>> Then I have to fix my changes by removing the redaction. That's my
>> example: I make a change that breaks my code and I get an error. I think
>> this behavior is desired.
>
> My point here is that the redaction doesn't give you anything, and
> therefore I don't see the point of adding it. It doesn't prevent any
> errors that would not be prevented without it, and it doesn't provide
> new functionality that is not currently available.
>
>> 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?
>>
>> This particular example is about discussion to allow reusing a variable
>> name after a redaction (or in general). If we allow redaction, the
>> question arises if we should allow or forbid reusing the variable name.
>> This is my point that we should forbid it! Because the programmer might
>> miss a later use of the variable when reusing a variable name. In
>> contrast to the example above where only redaction is allowed (with no
>> reuse of a variable name), in this case if we would allow it, the code
>> would silently change and the compiler cannot give an error.
>
> Whether a variable is "redacted" (i.e. the name is permanently banned)
> or "undeclared" (i.e. its name is made no longer reserved after the
> object and made available for new declarations), its usage will generate
> compilation errors anyway.
>
>> 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.
>>
>> And this was the point I was trying to make: "with the ability to reuse
>> the variable name" might be a bad idea because then you can change the
>> behavior of the program by mistake without an error by the compiler. If
>> we only allow redaction and it was a mistake, there will be an error
>> (that can easily be fixed by removing the redaction).
>
> Can you provide an example where undeclaring a variable would silently
> change code behavior and not cause a compilation error?
>
> I think, variable undeclaration, with the ability to reuse the name
> afterwards, adds a useful feature: it allows for reusing commonly used
> names for different purposes instead of having to enforce scopes or
> invent unique names. I often want to reuse short names like p, i, it, e,
> end, etc. in one function, and I could see myself using variable
> undeclaration to achieve that. OTOH, I don't see myself wanting to
> redact (i.e. permanently ban) a name.
>

re-using variables does make code reviews more difficult/time-consuming, we're only human...

Kind regards, Jonathan