c++ - What trait / concept can guarantee memsetting an object is well defined?

Question

Let's say I have defined a zero_initialize() function:

template<class T>
T zero_initialize()
{
    T result;
    std::memset(&result, 0, sizeof(result));
    return result;
}

// usage: auto data = zero_initialize<Data>();

Calling zero_initialize() for some types would lead to undefined behavior^{1, 2}. I'm currently enforcing T to verify std::is_pod. With that trait being deprecated in C++20 and the coming of concepts, I'm curious how zero_initialize() should evolve.

1. What (minimal) trait / concept can guarantee memsetting an object is well defined?
2. Should I use std::uninitialized_fill instead of std::memset? And why?
3. Is this function made obsolete by one of C++ initialization syntaxes for a subset of types? Or will it be with the upcoming of future C++ versions?

---

¹⁾ Erase all members of a class.
²⁾ What would be reason for “undefined behaviors” upon using memset on library class(std::string)? [closed]

Answer 1

There is technically no object property in C++ which specifies that user code can legally memset a C++ object. And that includes POD, so if you want to be technical, your code was never correct. Even TriviallyCopyable is a property about doing byte-wise copies between existing objects (sometimes through an intermediary byte buffer); it says nothing about inventing data and shoving it into the object's bits.

That being said, you can be reasonably sure this will work if you test is_trivially_copyable and is_trivially_default_constructible. That last one is important, because some TriviallyCopyable types still want to be able to control their contents. For example, such a type could have a private int variable that is always 5, initialized in its default constructor. So long as no code with access to the variable changes it, it will always be 5. The C++ object model guarantees this.

So you can't memset such an object and still get well-defined behavior from the object model.