[lmi] Special-members strategy categories [Was: depr.impldec]

[Greg Chicares]

[...popping at last the final unanswered bit of this discussion...]

On 7/10/22 12:29, Vadim Zeitlin wrote:
> 
>  FWIW here is my personal strategy for defining the class' special
> functions: there are several categories of classes
> 
> 1. Value-like: for them copy special functions and dtor are explicitly
>    defaulted. Move special functions are omitted, and are not available.
> 
> 2. Container classes: they're almost value-like, but typically require
>    defining move functions for efficiency reasons, so they're added,
>    and possibly defaulted.
> 
> 3. Polymorphic classes: for them, copy special functions are explicitly
>    deleted and a virtual dtor is defined and possibly defaulted. Move
>    special functions are omitted, and are not available as the result.
> 
> 4. All the rest: for them, copy special functions are explicitly either
>    default or deleted and the dtor is explicitly defined as well. Move
>    special functions can be explicitly defined if needed.

Before giving deep thought to each one, let me ask whether any of these
categories is actually empty for lmi. For example, wx has a large set
of containers, but I think lmi has none, at least not in the STL sense.
But lmi does have large set-of-named-data classes like LedgerVariant;
would those fall into the Containers category because (I'm supposing)
move functions might be helpful for them?

What about a class that contains, say, three vectors of a hundred
elements each? If it has no move special functions, then aren't the
vectors copied rather than moved? If so, would it be better to
place classes that contain STL containers in the Containers category?
and in that case, is the criterion really the size of the data the
class contains (whether directly or, as with a std::vector member,
indirectly)?

>  This seems relatively complicated, but IMHO is very logical and so not
> difficult to remember. It also requires in more typing, but I think it's
> worth to define the special copy functions explicitly as they can be a
> source of confusion and inefficiencies (e.g. large objects getting copied
> when they were not supposed to) otherwise.

Here again I perceive an emphasis on size: i.e., prefer to move
large objects instead of copying them.

Category (1) is small classes: don't move because it doesn't help.
Category (2) is large classes: move because we're sure it'll help.

I don't see why category (3) shouldn't be moveable.

Because I don't feel certain whether most classes are in one of
those three categories, I'd put most in all-other category (4),
for which the guidance is to enable copying or moving iff they
make sense. I think I'd approach that question in two steps:
 - If in C++98 a class would need to be copyable, then make it
   copyable, or moveable, or both. (I ask this question first
   because I think I already know how to answer it.)
 - Then, unless we don't want to copy or move it, implement
   copying if sensible, and also implement moving if the class
   has a lot of data.

Maybe I'm missing the point because I don't perceive crisp
criteria that determine which category a class belongs to.