Date: Thu, 27 Aug 2026 00:46:44 +0200
On 2026-08-27 00:03, Ted Lyngmo via Std-Proposals wrote:
> 2026-08-25 22:30, Tiago Freire:
>> Or maybe a std::destroy(), that burns a physical hole in your memory
>> so that it can never be re-used again....
>
> :-)
>
>> In all seriousness, we can discuss hypothetical features, but the
>> important part is it must have a point.
>> What problem you are trying to solve? Why would I want it solved?
>> Does this do that?
>>
>> Is there an answer to those questions?
> My impression is that it's to get a compilation error on redacted
> variables if one tries to use them and that this is to avoid common(?)
> errors occuring when using moved-from variables in an unsafe manner.
>
> I don't know how common it actually is but I have seen some cases
> where `std::forward` has been used multiple times on the same
> forwarding reference by mistake and I think this feature would catch
> at least some those mistakes. If it's enough of a problem to add the
> feature I don't know. Static analyzers also gets better and better so
> perhaps it'll be a none issue in a few years.
>
> If we go ahead with the idea then perhaps an alternative to a
> `std::redact`/`std::unredact` pair of functions with magic properties
> would be to take inspiration from clang's "consumable" attributes?
>
> [[clang::consumable(unconsumed)]] on the class
> [[clang::set_typestate(consumed)]] on the move constructor/destructive
> operations
> [[clang::callable_when(unconsumed)]] on member functions that require
> an unconsumed object
> [[clang::return_typestate(...)]]/[[clang::param_typestate(...)]] for
> propagating state through function boundaries.
>
> Vibe coded example: https://godbolt.org/z/nhjfsbKxv
>
> I noticed that it doesn't mark an object as consumed if one uses
> `Stream a = static_cast<Stream&&>(obj);` instead of `Stream a =
> std::move(obj);` so there are obvious gaps in the current implementation.
>
> Perhaps someone here's been involved in adding these attributes and
> could describe them in more detail (if they are "close enough" to
> what's been discussed for redact/unredact)?
>
> Br,
> Ted
>
> Ps. Sorry if this has already been up for discussion. I think I've
> missed a few messages in this thread.
Hi, I like that terminology "consumed", it reminds me of the original
idea for redact(): to prevent reuse of variables in typically larger
functions maintained by several people:
int munge(int raw)
{
int cooked = raw * 4711;
...
int cookagain = raw; // should have used cooked (we're done with
raw, it's "consumed")
}
However that attribute can only be applied to structs and classes,
right? I would like to be able to redact all types of variables.
P.S. The idea to use redact() as a std::move() companion came from
Ville, I haven't used a std::move() yet in my code :-)
> 2026-08-25 22:30, Tiago Freire:
>> Or maybe a std::destroy(), that burns a physical hole in your memory
>> so that it can never be re-used again....
>
> :-)
>
>> In all seriousness, we can discuss hypothetical features, but the
>> important part is it must have a point.
>> What problem you are trying to solve? Why would I want it solved?
>> Does this do that?
>>
>> Is there an answer to those questions?
> My impression is that it's to get a compilation error on redacted
> variables if one tries to use them and that this is to avoid common(?)
> errors occuring when using moved-from variables in an unsafe manner.
>
> I don't know how common it actually is but I have seen some cases
> where `std::forward` has been used multiple times on the same
> forwarding reference by mistake and I think this feature would catch
> at least some those mistakes. If it's enough of a problem to add the
> feature I don't know. Static analyzers also gets better and better so
> perhaps it'll be a none issue in a few years.
>
> If we go ahead with the idea then perhaps an alternative to a
> `std::redact`/`std::unredact` pair of functions with magic properties
> would be to take inspiration from clang's "consumable" attributes?
>
> [[clang::consumable(unconsumed)]] on the class
> [[clang::set_typestate(consumed)]] on the move constructor/destructive
> operations
> [[clang::callable_when(unconsumed)]] on member functions that require
> an unconsumed object
> [[clang::return_typestate(...)]]/[[clang::param_typestate(...)]] for
> propagating state through function boundaries.
>
> Vibe coded example: https://godbolt.org/z/nhjfsbKxv
>
> I noticed that it doesn't mark an object as consumed if one uses
> `Stream a = static_cast<Stream&&>(obj);` instead of `Stream a =
> std::move(obj);` so there are obvious gaps in the current implementation.
>
> Perhaps someone here's been involved in adding these attributes and
> could describe them in more detail (if they are "close enough" to
> what's been discussed for redact/unredact)?
>
> Br,
> Ted
>
> Ps. Sorry if this has already been up for discussion. I think I've
> missed a few messages in this thread.
Hi, I like that terminology "consumed", it reminds me of the original
idea for redact(): to prevent reuse of variables in typically larger
functions maintained by several people:
int munge(int raw)
{
int cooked = raw * 4711;
...
int cookagain = raw; // should have used cooked (we're done with
raw, it's "consumed")
}
However that attribute can only be applied to structs and classes,
right? I would like to be able to redact all types of variables.
P.S. The idea to use redact() as a std::move() companion came from
Ville, I haven't used a std::move() yet in my code :-)
Received on 2026-08-26 22:46:53
