C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Forget forget let's redact

From: Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>
Date: Mon, 24 Aug 2026 16:06:40 +0200
A few things I would like to mention as alternatives:

1. Immediately invoked lambdas: They may not solve all issues that redact
aims to solve, but it can at least scope the temporaries needed for
initialising a variable:
```
  auto my_array = [...] {
    auto some_temp_value = ...;
    std::array<T, n> values [[indeterminate]];
    std::ranges::generate(values, [some_temp_value] { return ...});
    return values;
}(); // immediately invoke the lamda, the temp-value(-s) only live in the
lambda scope.
```

2. One approach that kinda already works is to (ab)use the 'use-after-move'
check. It however does not seem to exist in gcc but rather in clang-tidy.
See: https://godbolt.org/z/Yc565GMfs . Having the compiler have a stronger
check for use-after-move together with a potential 'magic' relationship
with 'std::redact' that makes it improve its messages could be a way to
also implement this feature (as an alternative approach). It has the
benefit of improving the safety of code everywhere, but I can assume that
adding such a requirement in the standard could make it difficult to have a
compiler conforming for any but the most trivial cases (as the one shown
here).

3. Also remember that refactoring things into separate functions can also
be a viable way to accomplish the same goal. Taking your for-loop, you may
have : https://godbolt.org/z/n8fe49GM4 . I am not trying to shoot down your
proposal, but I am curious about what real-ish code would greatly benefit
from this that can't be solved by immediately invoked lambdas or separate
functions.

4. I sincerely do not believe std::unredact is a good idea, and I second
that the name should not be reusable in the same scope either. But that is
just IMHO.

// Robin

On Mon, Aug 24, 2026 at 3:22 PM Henry Skoglund via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2026-08-24 14:19, Jonathan Grant via Std-Proposals wrote:
>
> Could check state when calling redact() and unredact() too
>
> template<class T>
> class Redactable {
> T value_{};
> bool redacted_ = false;
>
> public:
> void redact()
> pre (!redacted_)
> { redacted_ = true; }
>
> void unredact()
> pre (redacted_)
> { redacted_ = false; }
>
> operator T&()
> pre (!redacted_)
> {
> return value_;
> }
> };
>
> On 24/08/2026 13:07, Sebastian Wittmeier via Std-Proposals wrote:
>
> Something like
>
>
>
> template<class T>
> class Redactable {
> T value_{};
> bool redacted_ = false;
>
> public:
> void redact() { redacted_ = true; }
> void unredact() { redacted_ = false; }
>
> operator T&()
> pre (!redacted_)
> {
> return value_;
> }
> };
>
>
>
> With the only magic being good error handing by the compiler or IDE?
>
>
> You mean wrapping the redactee in a template?
> I think it will be a less savory pill to swallow, assume the redactee is a
> function argument:
> int munge(MyType raw);
>
> with templates the function signature has to change to:
> int munge(Redactable<MyType> raw);
>
> Callers of that function then would have to update their code to support
> redacting :-(
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2026-08-24 14:06:58