> 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.