C++ Logo

std-proposals

Advanced search

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

From: Yongwei Wu <wuyongwei_at_[hidden]>
Date: Fri, 28 Aug 2026 19:33:31 +0800
Basically, you suggest adding attributes to achieve what clang-tidy
can do without attributes.

If somebody makes a class and does not add attributes to the certain
member functions, clang-tidy will still work, but the current approach
won't.

And I do not see how it is a better approach.

Stricter? Yes. Code made more complicated? Yes. Easy to learn and use?
Absolutely not.

I worry going down this way would be so patchy that Rust or Rusty
(a.k.a. Safe) C++ would look cleaner then.

By the way, what is the result of unredacting something twice? (The
code below would require it to have no effect on a normal variable)
Redacting something twice? (The second operation should result in an
error.) So we would likely have an asymmetry not quite obvious
according to the current names.

However, I am not here to completely negate this idea. We need better defaults.

An rvalue reference or a forwarding reference parameter should be
[[redact]] by default, unless it is marked [[no_redact]]. An
assignment operator should [[unredact]] this object (I do not think we
need a [[no_unredact]] here).

So only the `clear` member function needs to be marked.

On Fri, 28 Aug 2026 at 00:01, Ted Lyngmo via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> I had a similar idea to the "consumable" track with only two attributes,
> [[redact]] and [[unredact]]. Something along these lines:
>
> class string {
> public:
> string([[redact]] string&&);
>
> string& operator=([[unredact]] this string& self,
> [[redact]] string&& other );
>
> void clear([[unredact]] this string& self);
> };
>
> The move assignment operator would in this case unredact *this and
> redact whatever we "move from". It'd require reference tracking to
> survive through `std::move` and references bound to an lvalue. The
> lvalue and all named references to it should preferably be redacted all
> at once, no matter what name we used as an argument to the operator.

Received on 2026-08-28 11:33:53