Wouldn't it be good to have at least a manual way to specify, and a standard way to test, whether a type supports overlapping? E.g. a trait or concept? For types that do not support overlapping, memcpy is okay. Types that support overlapping should/would never touch their padding bits (and everybody else/outside should neither do). Then templates like optional<T> or shared_ptr<T> can choose whether to apply [[no_unique_address]] and compilers can better warn against using memcpy.   There possibly is also the advanced mixed case that you sometimes want to use [[no_unique_address]] and sometimes do memcpy & Co. *on the very same type*, but probably not the very same instance? But in that mixed case you would hide that subobject as private member variable or strictly keep it as base class to better control the operations on it.   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 04.12.2023 20:33 Betreff:Re: [std-proposals] std::sizeof_minus_trailing_padding An:std-proposals_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Sunday, 3 December 2023 23:08:07 PST Frederick Virchanza Gotham via Std- Proposals wrote: > > I think it's fine so long as you make it very obvious that you're not > allowed to use 'memcpy' or 'memset'. Maybe call it something like: > >     class optional_compacted_no_memset { . . . }; That's not the same thing as Arthur said. If you want to add a new class that has those extra constraints on top of std::optional and std::expected, then sure. He said it's not acceptable to add the attribute to those classes because they don't have and can't have this extra requirement on the user's template arguments.