Re: [lmi] Is this class moveable or not?

[Greg Chicares]

On 7/13/22 12:00, Vadim Zeitlin wrote:
> On Wed, 13 Jul 2022 00:06:28 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> Or does it actually prove nothing, for some reason
> GC> that transcends my rather limited understanding?
> 
>  The reason is very simple: defining your own move ctor overrides all the
> other considerations. You're completely changing the situation you're
> observing by doing it.

Aha!

This is much like the trap that Scott Meyers warned of, where we follow
the Rule of Zero, and then decide to define a dtor just as experimental
instrumentation, and find to our surprise that we've changed the behavior
because adding the dtor prevents some other special members from being
implicitly declared.

The difference here is that I replaced a declared, defaulted move ctor
that would be "defined as deleted" [class.copy.assign/7]
  [Note: I keep repeating that citation because I had formed a habit
  of referring to it as "implicitly deleted", but that's a different
  concept, so the habit must be unlearned --end note]
with a "user-provided" move ctor:
  gpt_server(gpt_server&&) {throw std::runtime_error("moved");}
which is not "defined as deleted" because [class.copy.assign/7] applies
only to defaulted members. Actually, that section concerns only
assignment operators, but this is a ctor so [class.copy.ctor/10] is the
applicable section, yet that section likewise says that only defaulted
members can be "defined as deleted".

And the fact that my "user-provided" move ctor doesn't cause it to be
"defined as deleted", again because [class.copy.ctor/10] doesn't apply.

>  Does this make sense?

Yes, now it does. Thanks: I didn't see that my "user-provided" move ctor
had revoked the "defined as deleted" property of the default version it
replaced--but my only motivation for writing it was to test that property.