Trivial, but not trivially default constructible
quuxplusone.github.io
quuxplusone.github.io
Probably not if there's any padding in the structure. Decently unlikely that T has a defined object representation at all though maybe that's changed in newer standards.
For example, we say that T is trivially copy-constructible iff T's copy constructor is defined such that making a copy of a T object is tantamount to making a copy of T's object representation (i.e., a memcpy). Given these two functions...
struct ObjRep { alignas(T) char data_[sizeof(T)]; };
void copy_value(T *s, T *d) { ::new (d) T(*s); }
void copy_repr(ObjRep *s, ObjRep *d) { ::new (d) ObjRep(*s); }
...if T is trivially copy-constructible, then these functions can (and in practice will) generate exactly the same code.Certain types are guaranteed by the Standard to be trivially fooable for certain foos (e.g. `int` is guaranteed to be trivially copyable, and so is `std::string_view` since C++23). Vice versa, it's often physically obvious when a type can't be trivially fooable; e.g. `std::string_view` can't possibly be trivially equality comparable. For most types, the Standard makes no guarantee, so different vendors may do different things... but each individual vendor must do some thing! And for most of these foos, we can just query a type-trait to find out what the compiler has done in the case of any given T.
Here's a godbolt where you can just fill in some data members and user-provided special member functions for `T`, and see the codegen for yourself. https://godbolt.org/z/97d3o3vbW
You mentioned padding bytes. Padding prevents trivial comparability, but does not affect any other trivial fooability that I can think of off the top of my head.