C.21 Rule of 5/6

Here is a counter argument to C.21: http://howardhinnant.github.io/classdecl.html

Imho there is such a thing as too much verbosity. I think it is better to learn when the compiler supplies, deletes or inhibits special member functions. Then ensure that all 6 of your member functions are correct (preferably with testing each one, even deleted ones). But not necessarily depend on user-declarations for all 6.

For example:

class day
{
    unsigned char d_;

public:
    day() = default;
    explicit constexpr day(unsigned d) noexcept;
    // ...

is far more readable than:

class day
{
    unsigned char d_;

public:
    ~day() = default;
    day() = default;
    day(day const&) = default;
    day& operator=(day const&) = default;
    day(day&&) = default;
    day& operator=(day&&) = default;
    explicit constexpr day(unsigned d) noexcept;
    // ...

And regardless one should have a unit test for this class that includes:

static_assert(std::is_trivially_destructible<day>{});
static_assert(std::is_trivially_default_constructible<day>{});
static_assert(std::is_trivially_copy_constructible<day>{});
static_assert(std::is_trivially_copy_assignable<day>{});
static_assert(std::is_trivially_move_constructible<day>{});
static_assert(std::is_trivially_move_assignable<day>{});
// ...

This test, more than the class declaration, ensures that class day has the desired design.

And the ordering of special members that are user-declared (as suggested in the linked article above), makes it easy for the reader to see which special members are intentionally compiler-declared.

Read guideline C.21 and the linked class-declaration article first. Compare the proposed treatment of special member functions and the suggested static assertions with the current guideline text. Done means reaching a maintainer-backed decision on whether C.21 should change and documenting the agreed wording.