I can understand "hey I don't expect this to be used again from this point forward, and let's catch those errors". In that case the identifier should still exist, only difference is the compiler stops you if you try to use it.

It's another thing to say "let's forget about this identifier, and we can re-use it again".
It's very hard to argue that "it is hard to refactor" because a different subsection in the same function uses the same identifier for a different purpose, when that could only happen if you have the source code and thus can change it.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jonathan Grant via Std-Proposals
Sent: Saturday, August 29, 2026 02:30
To: std-proposals_at_lists.isocpp.org
Cc: Jonathan Grant <jgrantonline_at_gmail.com>
Subject: Re: [std-proposals] Forget forget let's redact



On 25/08/2026 21:30, Tiago Freire via Std-Proposals wrote:
> 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?

I suggested before, programmers don't write long functions and re-use variables, also use -Wshaddow.

std::redact could help debugging issues if the function can't be refactored and modularised into separate scope areas, or separate functions, needs some design of the software.
adding std::redact(x) when a reviewer thinks the variable is no longer used, would find later uses and not compile.

Regards
Jonathan

>
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jonathan Grant via Std-Proposals
> Sent: Tuesday, August 25, 2026 18:46
> To: std-proposals_at_lists.isocpp.org
> Cc: Jonathan Grant <jgrantonline_at_[hidden]m>
> Subject: Re: [std-proposals] Forget forget let's redact
>
>
>
> On 25/08/2026 17:21, Simon Schröder via Std-Proposals wrote:
>> A moved-from object can still be reassigned and thus become valid again. This is about the variable name of the object. And there is precedent (as has been discussed in a previous thread before it has been renamed ‘forget’) with GCC which lets you ‘poison’ variables. And this is indeed used. What you are suggesting is at least different from what is already implemented by GCC.
>
> Perhaps need a std::banish(), so it can never be resigned and become valid again.
>
>>
>>> On Aug 25, 2026, at 9:40 AM, Rune Lund Olesen via Std-Proposals <std-proposals_at_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_at_lists.isocpp.org <mailto:std-proposals_at_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_at_lists.isocpp.org <mailto:std-proposals_at_lists.isocpp.org>>
>>> *Gesendet:* Mo 24.08.2026 15:22
>>> *Betreff:* Re: [std-proposals] Forget forget let‘s redact
>>> *An:* std-proposals_at_lists.isocpp.org <mailto:std-proposals_at_lists.isocpp.org>;
>>> *CC:* Henry Skoglund <henry_at_tungware.se <mailto:henry_at_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_at_[hidden] <mailto:Std-Proposals_at_lists.isocpp.org>
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_lists.isocpp.org>
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_lists.isocpp.org
>>> 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