Il 29/01/23 22:19, Jason McKesson via Std-Proposals ha scritto:
> 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.

Do you mean that the type is not "really useful" in practice (that is,
the example is completely artificial), or are you asking what the
current rules are?

First and foremost I'd rather not carve any exceptions based on
"perceived usefulness". Second, maybe something like

class Point { public: int tag; private: int x, y; };

may be a better example.

My point stands, there's no type classification today that is correct
and complete.


> 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.

I'm not sure what you mean here? There's no either-or: if you
value-initialize the object, it's zero initialized; it's never
uninitialized. (As discussed in the paper, value initialization of a
trivially default constructible class always goes through zero
initialization.)


> 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.

I'm really really really not sure about the implications of adding
implicit lifetime types to the mix. What you say above makes lots of
sense, but how in the world is the compiler supposed to know if

struct Foo {
   int i;
   Foo(); // non-trivial, user-provided, out of line, ...
};

can or cannot be value-initialized by zero-filling storage? Foo is an
implicit-lifetime class: it has a trivial _copy_ constructor and trivial
destructor.


Thank you,

-- 
Giuseppe D'Angelo