On 2026-08-23 23:36, Henry Skoglund wrote:
> 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
>
Aah (sorry a bit dim today) now I see, you mean if your
     int x = 11;

with -Wshadow and the first x redacted would not emit any shadow warning.
In the best of worlds gcc could say something similar to:
<source>:9:13: warning: declaration of 'x' shadows a previous redacted
local [-Wshadow]