Date: Sat, 22 Aug 2026 23:53:40 +0200
On 2026-08-22 09:18, Ted Lyngmo via Std-Proposals wrote:
> 2026-08-17 02:12, Henry Skoglund:
>> Hi, I reread all replies to my previous "forget" post, I think I'm
>> smarter now :-)
>> Here's my new take: let's introduce a std::redact() primarily for
>> safety reasons:
>> void f()
>> {
>> int a = 42;
>> int b = 41;
>> b = std::move(a);
>> std::redact(a);
>> int c = a; // <--- error: a is redacted, cannot be used
>> }
> If we get std::redact, wouldn't we also want std::unredact to be able
> to still clear() variables in a valid but unspecified state?
>
> for(std::string line; std::getline(std::cin, line);) {
> vec.push_back(std::move(line));
> std::redact(line);
>
> // ... line unusable here ...
>
> std::unredact(line);
> line.clear();
> }
>
> 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:
>
> for(std::string line; std::getline(std::cin, line);) {
> vec.push_back(std::redact(line));
>
> // ... line unusable here ...
>
> std::unredact(line).clear();
> }
>
> Br,
> Ted
Thank you, pretty nice idea. As long as std::unredact() follows the same
playrules as std::redact():
A std::unredact() is only valid in the same scope as a previous
std::redact() on the same redactee.
And in the same control path in case of switches or gotos etc.
A program compiled ok with std::unredact() should have the same runtime
behavior as the same program compiled without the std::redact() and the
matching std::unredact().
And a std::unredact() without a previous std::redact() on the same
redactee should constitute an error.
Perhaps we should restrict the number of redacts and unredacts you can
do, e.g.:
void f()
{
int a = 42;
int b = 41;
b = std::move(a);
std::redact(a);
...
std::unredact(a);
...
std::redact(a); // <-- error: can only do this once
}
Re. std::redact() and std::unredact() returning flavors of T:s:
I grant you it would be convenient to be able to push_back directly on
the std::redact() but it hurts my brain a bit.
I feel like a noob in this mailing list (for example I had to google
std::remove_reference :-) but anyway, let's start simple: keeping the
std::redact() and std::undredact() on separate lines returning nothing
for now...
> 2026-08-17 02:12, Henry Skoglund:
>> Hi, I reread all replies to my previous "forget" post, I think I'm
>> smarter now :-)
>> Here's my new take: let's introduce a std::redact() primarily for
>> safety reasons:
>> void f()
>> {
>> int a = 42;
>> int b = 41;
>> b = std::move(a);
>> std::redact(a);
>> int c = a; // <--- error: a is redacted, cannot be used
>> }
> If we get std::redact, wouldn't we also want std::unredact to be able
> to still clear() variables in a valid but unspecified state?
>
> for(std::string line; std::getline(std::cin, line);) {
> vec.push_back(std::move(line));
> std::redact(line);
>
> // ... line unusable here ...
>
> std::unredact(line);
> line.clear();
> }
>
> 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:
>
> for(std::string line; std::getline(std::cin, line);) {
> vec.push_back(std::redact(line));
>
> // ... line unusable here ...
>
> std::unredact(line).clear();
> }
>
> Br,
> Ted
Thank you, pretty nice idea. As long as std::unredact() follows the same
playrules as std::redact():
A std::unredact() is only valid in the same scope as a previous
std::redact() on the same redactee.
And in the same control path in case of switches or gotos etc.
A program compiled ok with std::unredact() should have the same runtime
behavior as the same program compiled without the std::redact() and the
matching std::unredact().
And a std::unredact() without a previous std::redact() on the same
redactee should constitute an error.
Perhaps we should restrict the number of redacts and unredacts you can
do, e.g.:
void f()
{
int a = 42;
int b = 41;
b = std::move(a);
std::redact(a);
...
std::unredact(a);
...
std::redact(a); // <-- error: can only do this once
}
Re. std::redact() and std::unredact() returning flavors of T:s:
I grant you it would be convenient to be able to push_back directly on
the std::redact() but it hurts my brain a bit.
I feel like a noob in this mailing list (for example I had to google
std::remove_reference :-) but anyway, let's start simple: keeping the
std::redact() and std::undredact() on separate lines returning nothing
for now...
Received on 2026-08-22 21:53:46
