On 2026-08-12 17:41, Andrey Semashev via Std-Proposals wrote:
> 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.
>
Sorry yes, for a while there I forgot the difference between
compile-time and run-time and in which one the poisoning/redacting occurs.
(Maybe you can tell by now I'm not a C++ expert :-)

Now I know more about control flow and I agree, my fancy
std::move_and_redact<> template will remain a pie in the sky for now.

But if a future C++ reflection version could provide a copy of the
compiler's tracking of control flow, then perhaps...