Re: auto-generated move assignment and base or member with a by-value assignment

You are mixing two different concepts here: One concept is the core
language concept of special member functions and these do specify that
this class has a copy-assignment operator. Having a copy-assignment that
also requires the existence of a move- or copy-constructor is not very
useful, though. But this is not very special for move operations. You
could alternatively declare the destructor as deleted without
introducing any deleted copy/move constructor and the type still would
not be able to copy-assign or even construct in a normal variable
definition.

The other concept is a an expression-based concept from the Standard
Library: Copy/MoveConstructible and Copy/MoveAssignable. Both concepts
are based on valid expressions, but they do not directly depend on the
existence of the core language special member functions. For example a
type without any special move member can still satisfy the
MoveConstructible or MoveAssignable concepts, if it has accessible and
non-deleted special copy member functions.

Trying to deduce from the existence (or absence) of special members (the
core language concept) the expression behaviour (the library concept),
is a false analogy and can lead to surprises. E.g. the following type
does have a deleted default constructor, but still can be
aggregate-initialized:

struct S {
   S() = delete;
};

S s1; // Error
S s2{}; // OK, aggregate initialization

These traits are referring to initialization forms and are not bound to
the existence or absence of special members. That was not always the
case. In fact the corresponding TR1 traits like has_trivial_copy,
has_trivial_assign, or has_nothrow_copy were in fact inspecting the
properties of special member functions. In this regard, the new
is_copy/move_* traits are testing "expression" semantics and are more
similar to the Library requirement sets (but do not impose behavioral
requirements) and are often considered as more useful. Still, we have
traits that solely inspect properties of core-language concepts, such as
is_trivial or is_trivially_copyable. For example, the following type is
trivially copyable, albeit it is not default-constructible,
copy/move-constructible, copy/move assignable nor destructible:

struct TC {
   TC() = delete;
   TC(const TC&) = delete;
   TC(TC&&) = delete;
   TC& operator=(TC&&) = delete;
   TC& operator=(const TC&) = delete;
   ~TC() = delete;
};

I have understood that your are comparing the core language definitions
of the special member functions with a different concept set. This was
the reason why I said in my previous response starting with "But I
understand the point that you are trying to make". Please keep in mind
that both concepts domains are different, albeit the core language
concept has impact on the outcome of the library concept.

HTH & Greetings from Bremen,
Daniel Kr?gler