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: So 23.08.2026 23:37
Betreff: Re: [std-proposals] Forget forget let‘s redact
An: std-proposals@lists.isocpp.org;
CC: Henry Skoglund <henry@tungware.se>;
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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals