It's assignment even in the case of POD members. The only difference
is the dimwitted inconsistency that sometimes POD's don't get default
initialized.
Sorry, Ron, I did not get you fully. The constructor body syntax is
assignment but the member remains unitialized. I refer to
[class.base.init]/4:
If a given non-static data member or base class is not named by a mem-
initializer-id (including the case where there is no mem-initializer-
list because the constructor has no ctor-initializer), then
-- If the entity is a non-static data member of (possibly cv-
qualified) class type (or array thereof) or a base class, and the
entity class is a non-trivial class, the entity is default-initialized
(8.5). If the entity is a non-static data member of a const-qualified
type, the entity class shall have a user-provided default constructor.
-- Otherwise, the entity is not initialized. If the entity is of
const-qualified type or reference type, or of a (possibly cv-
qualified) trivial class type (or array thereof) containing (directly
or indirectly) a member of a const-qualified type, the program is ill-
formed.
The "otherwise" part is the one that covers POD types. So, as per
above, they remain uninitialized until the assignment happens. Prior
to that assignment, no initialization has happened. So, using a member
initialization list or not for POD, doesn't make much difference. The
expression inside the body is assignment though. Is this what you are
trying to point out? What do you mean by "sometimes POD's don't get
default initialized"? In which cases does default initialization
happen for PODs (considering an empty initializer list)?