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.