On 12 Aug 2026 18:08, Simon Schröder wrote:
>
>
> On Wed, Aug 12, 2026 at 4:41 PM Andrey Semashev via Std-Proposals <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> On 12 Aug 2026 16:26, Simon Schröder wrote:
> >
> >
> [...]
> >
> > 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?
>
> It's probably a contrived example, so you have to imagine a more
> complicated and longer function in the real world.
>
> Assume that the following is the original code:
> auto myFunction()
> {
> double x = std::sqrt(2.0);
> // lots of other code
> return x;
> }
> Then someone comes in and does a few additions:
> auto myFunction()
> {
> double x = std::sqrt(2.0);
> // some of the previous code
> redact x; // redact the variable because the programmer assumed that
> it wasn't used anymore
> int x = 42; // if we allow reuse after redaction: maybe I just
> redacted the variable to reuse the name
> // some more of the previous code (and probably also a use of the
> new 'x')
> return x; // no compiler error here, but changed behavior
> }
>
> Compilation after the changes were done cannot catch that the type of
> 'x' in the return statement has changed. We would need a rule for the
> programmer that after every redaction you need to recompile to make sure
> the redaction was valid. Only after you have made sure that the
> redaction is valid can you reuse the variable name. But it is not a rule
> that can be enforced by a compiler (maybe an IDE could track the changes).

Well, of course you have to examine the code that can be directly
affected by your change. You could just add any code that affected x in
the middle of the function and then get surprised that it affected the
returned value. Adding support for undeclarations does not change that.

My point was that adding just `redact x;` (where the effect of this
statement would be undeclaring x, as I described it earlier) does not
silently change the code behavior, same as with redacting (i.e. with
banning the name).