Date: Wed, 12 Aug 2026 18:41:27 +0300
On 12 Aug 2026 18:27, Henry Skoglund via Std-Proposals wrote:
>
> 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...
Again, as I noted in my other reply, these use cases do not necessitate
banning the name of the variable from future reuse. All you need is to
prevent binding the name to the original object after a certain point in
the program. This I could see as being useful, as it still allows for
reusing the names.
Sebastian Wittmeier has brought up an interesting question of how this
mechanism would interact with control flow. Obviously, a name cannot be
conditionally redacted, so my understanding is that redacting should
happen in the same scope as the declaration. This also means your
std::move_and_redact or similar helper functions should not be possible,
other than through some compiler magic.
>
> 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...
Again, as I noted in my other reply, these use cases do not necessitate
banning the name of the variable from future reuse. All you need is to
prevent binding the name to the original object after a certain point in
the program. This I could see as being useful, as it still allows for
reusing the names.
Sebastian Wittmeier has brought up an interesting question of how this
mechanism would interact with control flow. Obviously, a name cannot be
conditionally redacted, so my understanding is that redacting should
happen in the same scope as the declaration. This also means your
std::move_and_redact or similar helper functions should not be possible,
other than through some compiler magic.
Received on 2026-08-12 15:41:36
