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:So 23.08.2026 23:37 Betreff:Re: [std-proposals] Forget forget let‘s redact An:std-proposals_at_[hidden]; CC:Henry Skoglund <henry_at_[hidden]>; On 2026-08-23 17:00, Jonathan Grant via Std-Proposals wrote: > > On 23/08/2026 06:52, Simon Schröder via Std-Proposals wrote: >> >>> On Aug 23, 2026, at 1:24 AM, Henry Skoglund via Std-Proposals <std-proposals_at_[hidden]> wrote: >>> >>> On 2026-08-23 01:12, Ville Voutilainen wrote: >>>> On Sun, 23 Aug 2026 at 00:53, Henry Skoglund via Std-Proposals >>>> <std-proposals_at_[hidden]> wrote: >>>>>> For ergonomics, I'd prefer an inferface where redact returns >>>>>> std::remove_reference_t<T>&& like std::move and unredact returns T& so >>>>>> that one could do: >>>>> Thank you, pretty nice idea. As long as std::unredact() follows the same >>>>> playrules as std::redact(): >>>> It's a nice idea, yes. Ted is completely correct that it's a nice >>>> idea, and could be useful for some cases. >>>> >>>> I'm not even against Ted's idea. I just want to suggest that we keep in mind >>>> >>>> return -ENOTENOUGHBANGFORTHEBUCKESPECIALLYFORTHECOMPLEXITY; >>>> >>>> I seriously don't have a strong opposing viewpoint here. Being able to >>>> poison name lookup seems handy. >>>> Being able to poison the lookup and then unpoison it.. ..seems.. >>>> ..questionable. The former I could explain. >>>> The latter.. ..I would struggle  to explain. >>> Yes let's agree std::redact() is the main race horse to bet on here, and a std::unredact() could be a future, separate proposal. >> In the beginning of this discussion, people heard std::redact and immediately thought: Can I then reuse the variable name? This clashes with std::unredact. In the most extreme case we could allow both, but only either one of them can be used; i.e. if I reuse the variable name I can no longer unredact the “shadowed” variable. > > Well, we can re-use the variable name in a separate scope. std::redact(x) makes it clear that the earlier x cannot be used. > > int x = 10; > std::redact(x); > > { >      int x = 11; >      std::cout << x << "\n"; > } > > // Compiler diagnostic. Makes a programmer think > std::cout << x << "\n"; > > However, for human reasoning, isn't it safer to use smaller functions, and avoid re-using variable names? Smaller possible control-flow paths, simpler states. Making lifetime boundaries simpler, ownership etc. Reducing accidental confusion about which value is being used. > > gcc, clang already warn with -Wshadow > How would std::redact work with this, presumably no compiler diagnostic if std::redact(x); ? > > https://godbolt.org/z/chfqfffM7 > > Regards > Jonathan The redacting of x would ignore that inner scope/block so from std::redact()'s point of view it should be equivalent to: int x = 10; std::redact(x); // Compiler diagnostic. Makes a programmer think std::cout << x << "\n"; // <--- error: x is redacted -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals