On 13/08/2026 23:56, Jarrad Waterloo wrote:
> "re-using variables does make code reviews more difficult/time-consuming, we're only human..."
>
> NOT, when it is the same object and you are just restricting access to it

That's a good point. It's simple enough already to implmement the following - if that would fit the use case?

Forget<int> a(42);
a.disable_access();

// Error constraint violation compile error
 __builtin_printf("a %d\n", x);

a.enable_access();

// This will work
 __builtin_printf("a %d\n", x);

Kind regards
Jonathan

>
> also creating to many superfluous aliases from not shadowing in these safer caes makes code reviews worse
>
>
> On Thu, Aug 13, 2026 at 6:13 PM Jonathan Grant via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
>
>
> 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:proposals_at_[hidden]> <mailto: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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>