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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Mo 24.08.2026 15:22
Betreff: Re: [std-proposals] Forget forget let‘s redact
An: std-proposals@lists.isocpp.org;
CC: Henry Skoglund <henry@tungware.se>;
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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
 
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


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