Re: [lmi] Detecting whether move semantics actually take place

[Greg Chicares]

On 7/23/22 15:41, Vadim Zeitlin wrote:
[...]
>  First, and trivially, you should sprinkle magic constexpr dust all over
> your code

Done, in the second-oldest change here:

  origin/odd/move_semantics
4c41e5790 Expunge a semiotic nightmare
cc46b95a1 Use 'concept' syntax
f09746b48 Expand commentary
03e061cf6 Replace run-time with compile-time tests
2fbb26c9f Improve documentation

>  Second, I think this would work even better with concepts rather than
> simple template functions, both because the former are slightly more
> readable (even if the functions here are pretty clear too) and because they
> result in much better error messages, similar to the clang warning above,
> except that this also works with gcc, if the requirement fails.

That's the second-youngest change above. It's a straightforward
mechanical change, almost as simple here as
  s/constexpr bool/concept/
but this isn't the use case for which 'concepts' were designed.

Right now I'm just staring at:

struct can_copy
{
   can_copy() = default;
   can_copy(can_copy const&) = default;
   can_copy(can_copy&&)      = delete;
   can_copy& operator= (can_copy const&) = default;
   can_copy& operator= (can_copy&&)      = delete;
};

can_copy a {};
can_copy b {a}; // Looks copy-constructible to me.
can_copy c = b; // And copy-assignable, too.

static_assert(std::copyable<can_copy>);
static_assert(std::copy_constructible<can_copy>);      // fails
static_assert(std::is_copy_constructible_v<can_copy>); // succeeds

I do understand why they designed each of these predicates,
but including them all is embarrassing: they might at least
have deprecated the name of the last one in favor of, say,
"possesses_a_copy_constructor".

And I do understand the discussions that dismiss that example
as bad code that should never be written. But that doesn't
excuse the confusion caused by these two:
     copy_constructible
  is_copy_constructible
having different meanings.