Re: [lmi] default-member-initializers vs. is_trivial

[Greg Chicares]

On 4/19/21 9:30 PM, Vadim Zeitlin wrote:
> On Mon, 19 Apr 2021 20:57:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> The task of the constructor is to actually initialize (or
> not) the new object data and trivial constructor doesn't do it.

That's exactly my point.
  Constructors actually initialize things.
  "Trivial ctors" don't.
  Therefore "trivial ctors" aren't constructors.
They're nonconstructors, or semiconstructors. They don't create
(usable) objects; they create husks.

> GC> I suppose that's useful for...creating a vector of objects that cannot
> GC> be used because they're uninitialized? Was that the goal? Why would
> GC> such a goal be desirable? Surely I'm still missing something.
> 
>  Sorry, but this seems a very strange question to me. What's the goal of
> having C structs that always behave like this?

Well, that's obvious. And the goal of having C++ constructors is that
they don't behave like that: they initialize data members.

> It's exactly the same thing
> in C++: at this level, you define a struct to be able to name chunks of
> memory and operate with them in type-safe way. There are plenty of reasons
> it can be good even if you don't initialize this memory. The most common
> ones I can think of would be:

[...snip several good systems-programming examples...]

> I'm sure there are other scenarios, but, mostly, this is just how things
> have always worked for our forbears, and so, of course, this must be the
> only way for them to work. Wait, maybe this argument isn't that persuasive,
> after all... But, still, why are you suddenly surprised by this when it
> has, indeed, always worked like this since the very beginnings of C?

I wouldn't have been confused at all if they had made it clear
that "triviality" is a low-level concept intended for systems
programmers and library authors. Having first contemplated
trivial-copyability, I had surmised that "triviality" was a
generally desirable property of classes--a precondition that
ensures that compiler-generated special member functions do
the right thing--a prerequisite for the rule of zero to be
generally applicable.