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_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).
>
>
>
> -
>

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...