I am not sure whether everyone here knows, but clang-tidy can already
recognize dangerous use of an object after a move. It is even cleverer, as
it can recognize the "reinitialization" operations that make the object
"active" again.

So I do not think `redact` should have anything to do with `move`, unless
we make it a very complicated feature so that "reinitialization" will
reactivate the object automatically. I do not think it is a direction worth
pursuing.

On Tue, 25 Aug 2026 at 15:40, Rune Lund Olesen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello
>
> Im not sure if this has been discussed already, maybe this idea (redact)
> should (also) be possible to specify with a move constructor or any member
> function really ?
>
> That is, a "move from an object" can either leave the object in an invalid
> state but other times a valid one (many times an empty but still valid
> container for example).
>
> So, if declared, "a move from" will "redact" the object automaticly (then
> possibly produce a malformed program if used again later).
> That way it does not pollute the "user code" so much.
>
> The biggest concern I have with this propasal is it feels maybe too niche
> to actually solve much in real production code (?).
> Among all the other "footguns" we have, this feels very niche and we
> already can do block scopes inside functions to limit the lifetime of eg. a
> "moved from object" in some situations.
>
> Also we have had this same situation forever with pointers (swapping
> pointers around). At the very least this should be applicable to pointers
> too but I guess it is.
>
> But, anyway, the idea is very welcome as I see it: we need to think
> "outside the box" to make c++ safer for everyone.
>
> Rune :)
>
>
>
> On Mon, Aug 24, 2026 at 5:20 PM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> The original post contained the lines below (end of my post).
>>
>> It would use dereference * or get() or implicit conversion to get the
>> actual type out for function calls or each usage.
>>
>> As advantages,
>>
>> - the feature would be more contained (no large language change)
>>
>> - this is a dynamic redact proposal, considering the full program flow
>> (we can have a for loop from 0 to 99 and redact the variable in iteration
>> 50); it would reuse the precondition contracts checks
>>
>> - as it is a scoped (automatic) variable, the boolean can be optimized
>> out
>>
>> - it could help thinking about it to improve the full std::redact
>> proposal. Even if my alternative is ugly and never to be accepted. Just to
>> have an alternative can have advantages. Understand the commonalities and
>> differences. Have a different perspective, how it works or could work.
>>
>>
>>
>>
>>
>> > How about solving it as
>>
>> > std::redactable<T>
>>
>> > similar to std::optional<T>?
>>
>> > It could still be a magic (templated) class going beyond the
>> capabilities of pure library solutions.
>>
>> > If it isn't redacted, it supports implicit conversions, * or get().
>>
>> > At least it could make sense to compare the two syntaxes or necessary
>> language changes.
>>
>> > The changes within std::redacted<> are better contained in the
>> standard, which could increase acceptance (perhaps).
>>
>> > It could be solved by actually storing a bool and detect redaction at
>> runtime. If the program flow can be proven the optimizer can remove the
>> redaction bool (it is an automatic/local scoped stack variable after all).
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Henry Skoglund via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mo 24.08.2026 15:22
>> *Betreff:* Re: [std-proposals] Forget forget let‘s redact
>> *An:* std-proposals_at_[hidden];
>> *CC:* Henry Skoglund <henry_at_[hidden]>;
>> On 2026-08-24 14:19, Jonathan Grant via Std-Proposals wrote:
>>
>> Could check state when calling redact() and unredact() too
>>
>> template<class T>
>> class Redactable {
>> T value_{};
>> bool redacted_ = false;
>>
>> public:
>> void redact()
>> pre (!redacted_)
>> { redacted_ = true; }
>>
>> void unredact()
>> pre (redacted_)
>> { redacted_ = false; }
>>
>> operator T&()
>> pre (!redacted_)
>> {
>> return value_;
>> }
>> };
>>
>> On 24/08/2026 13:07, Sebastian Wittmeier via Std-Proposals wrote:
>>
>> Something like
>>
>>
>>
>> template<class T>
>> class Redactable {
>> T value_{};
>> bool redacted_ = false;
>>
>> public:
>> void redact() { redacted_ = true; }
>> void unredact() { redacted_ = false; }
>>
>> operator T&()
>> pre (!redacted_)
>> {
>> return value_;
>> }
>> };
>>
>>
>>
>> With the only magic being good error handing by the compiler or IDE?
>>
>>
>> You mean wrapping the redactee in a template?
>> I think it will be a less savory pill to swallow, assume the redactee is
>> a function argument:
>> int munge(MyType raw);
>>
>> with templates the function signature has to change to:
>> int munge(Redactable<MyType> raw);
>>
>> Callers of that function then would have to update their code to support
>> redacting :-(
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/