2026-08-27 00:46, Henry Skoglund:
> On 2026-08-27 00:03, Ted Lyngmo via Std-Proposals wrote:
>>
>> If we go ahead with the idea then perhaps an alternative to a
>> `std::redact`/`std::unredact` pair of functions with magic properties
>> would be to take inspiration from clang's "consumable" attributes?
>>
>
> Hi, I like that terminology "consumed", it reminds me of the original
> idea for redact(): to prevent reuse of variables in typically larger
> functions maintained by several people:
> int munge(int raw)
> {
> int cooked = raw * 4711;
> ...
> int cookagain = raw; // should have used cooked (we're done with
> raw, it's "consumed")
> }
>
> However that attribute can only be applied to structs and classes,
> right? I would like to be able to redact all types of variables.
I haven't tried them out that much. Perhaps it's not possible to make an
`int` consumable and I think I'd buy the reasoning behind that even
though consistency is nice.

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.

An unredacting function (member or non-member) would have to follow some
rules:

void func([[unredact]] string& str) {
// The variable (the lvalue + references to it) passed to func is
// unredacted while `str` inside the function is redacted upon entry.
//
// compilation error if
// - The first str member used is not an unredacting member function
// - The function can return with str redacted (all branches must be
// proven to lead to leaving the function with str unredacted,
// exception handling may be tricky)
// - I had some other thoughts about rules but forgot them :-)
}

Perhaps a side track from the original idea but I think it's interesting
to reason about what kind of redaction logic we could get in place
without touching too much of existing user-code. If it would be possible
to make the std::string API as above, the idea is that code that already
uses `std::string` correctly would not need to be touched.

Br,
Ted