On 2026-08-12 17:08, Simon Schröder via Std-Proposals wrote:


On Wed, Aug 12, 2026 at 4:41 PM Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> 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).


-

Hi, my original use case was others adding code to my functions and picking up on the wrong variable (e.g. raw instead of cooked), so it wasn't any temporary variables (like i) that I wanted to poison.

I wanted a function template like:
    cooked = std::burn_after_reading<raw>;
The function template could contain the copying, the redact statement and returning the copy, and hopefully the compiler would optimize away the function.

A more suitable name might now be:
    cooked = std::move_and_redact<raw>;

This type of "improved move" could be a simple stepping stone to our own borrow checker/safer C++. Maybe I've had too much coffee but imagine a standard library where all the moves also redacted the original...