~Foo() *: value_{42}* {} = default;

Would making destructors more like constructors by adding a [de]initializer
list make it easier on the compiler since it no longer has to analyze the
function body.

It is really disheartening that such a simple type when aggregated would
disqualify that type from being 'implicit lifetime type" or any of the
other naming requirements that depend upon default destructors.

...

By the way, doing a [contract pre] assert on the success value in GCC and
clang works by requiring that a reference refers to a [likely] live object
or more importantly definitely not dead object. However, the type is no
longer 'implicit lifetime type" for something ridiculously simple..



On Sat, Jan 10, 2026 at 11:25 AM Peter Bindels via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> The solution I have for securely erasing storage for an instance is to
> control where that instance can be allocated, and to make the clearing of
> space on destruct to be the responsibility of the allocator (who still owns
> the memory and has it in its lifetime), not the object. The object itself
> cannot do it, but the allocator can.
>
> Not 100% a fix for secure types though, since they can still be swapped
> out, held in registers during process swaps, or seen by external processes.
> Two of these three can be fixed with OS-specific calls, the last needs
> compiler and OS support to do. Might be a paper at some point.
>
> On Sat, Jan 10, 2026 at 5:22 PM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Clearing out memory is difficult to make reliable, if the effect is not
>> observable.
>>
>>
>> -----Ursprüngliche Nachricht-----
>>
>> Think secure_string or secure_array clearing out memory in a specific way.
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>