On Sun, Jan 29, 2023 at 4:11 PM Jason McKesson <jmckesson_at_[hidden]> wrote:
>
> On Sun, Jan 29, 2023 at 3:41 PM Giuseppe D'Angelo via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hello,
> >
> > As per subject, I've been working on a proposal for a standardized way
> > to detect if a trivially default constructible type can be value
> > initialized by using `memset(0)` on some suitable storage.
> >
> > A draft is available here:
> >
> > https://isocpp.org/files/papers/D2782R0.html
> >
> > As usual, any early feedback is very much appreciated. I am not 100%
> > convinced about the name of the trait, as I'm trying to model something
> > for which there isn't already an established name/concept. I hope the
> > discussion/bikeshedding can wait after everything else has been ironed
> > out...
>
> I don't like that the set of such types is so broadly
> implementation-defined. We need something more concrete.
>
> I would suggest that a type is "trivially zero-initializable" if:
>
> 1. If it is a class type:
> 1a. It is an implicit lifetime type
> 1b. All of its non-static data members and base classes are
> themselves implicit lifetime types
> 2. It is an arithmetic type
> 3. It is an enumeration type
> 4. It is `nullptr_t`
> 5. The other fundamental types are all implementation defined.
> However, I would suggest that it should be equally true/false for all
> pointers of the same category: object pointers, function pointers, and
> member pointers. Either all object pointers are
> trivially-zero-initializable or none of them are. Etc.
> 6. No reference types are trivially-zero-initializable.
>
> Also, how does Itanium-based code work if you have a member pointer in
> static storage that gets zero-initialized? Does something have to
> manually fill in the -1s at runtime, or does an object containing such
> a member pointer have to take up space in static executable storage?

First, I meant to say "All of its non-static data members and base
classes are themselves trivially-zero-initializable", not "implicit
lifetime types".

Second, I forgot to add an explanation for using "implicit lifetime"
instead of "trivially default constructible" as a condition for class
types. One of your examples had a class with a public and a private
member. Well, it's entirely unclear what it would mean for that type
to be trivially default constructible. Either the private member goes
uninitialized or it gets zero-initialized, and either state is
considered valid. This to me seems like a rather confused type, and we
should probably avoid letting that sort of thing go.

It also makes a lot of sense to be able to zero out some memory and
then invoke `start_lifetime_as` upon the objects in it. And some
implicit lifetime types are not trivially default constructible, but
they can still have `start_lifetime_as` invoked upon them. So at the
very least, it should be either implicit lifetime or trivially default
constructible.