[lmi] const or reference members [Was: When in doubt, prefer the Rule of Five to the Rule of Zero]

[Greg Chicares]

On 7/12/22 21:40, Vadim Zeitlin wrote:
> On Tue, 12 Jul 2022 16:18:34 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 7/11/22 22:12, Vadim Zeitlin wrote:
> GC> > On Mon, 11 Jul 2022 16:22:14 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> GC> > 
> GC> > GC> On 7/11/22 12:12, Vadim Zeitlin wrote:
[...]
> GC> > GC> Here, I want to consider a distinct question: if, for any given 
> class,
> GC> > GC> defaulted copy operations are correct, then can default assignment
> GC> > GC> operations be incorrect?
> GC> > 
> GC> >  It's, of course, possible to maliciously design just such a class, but 
> I
> GC> > don't think it's something that can happen organically.
> GC> 
> GC> I stumbled on one case: const reference members. I suppose either
> GC> const-ness or reference-ness is enough to poison assignment.
> 
>  Either is enough for the assignment not to be possible, but for me this
> doesn't mean it's incorrect -- it's disallowed, which is something quite
> different (and not nearly as bad).

Let me paraphrase, to see whether I understand:

Given a class with const or reference members, in our editor we can add
defaulted assignment operators, but our compiler will reject them.
It won't accept them and generate invalid code.

Is that equivalent to what you said?

> My answer above was to the question of
> whether a class with a working defaulted copy ctor could have a broken
> default assignment operator and I still think that this shouldn't happen.
> Sorry if I had misunderstood your question...

I'm no longer sure exactly what I was trying to ask, but I believe
I was asking in the context of believing the opposite of what you
said above, or at least of my paraphrase of it.

> GC> Whether that's "organic" or not, the fact remains that I've done
> GC> it in a few places, so the question becomes whether to un-do it.
> 
>  Sorry, I'm not sure what exactly do you propose to undo (or not).

I've written classes with const or reference members. I'm wondering
whether I should repent and change them all. I don't feel any great
urgency about this.

OTOH, I recently found a case where changing a non-const non-reference
member to "const&" would permit a forward declaration where an entire
header is now included:

  -#include "round_to.hpp"
  +template<typename> class round_to;

  ...and change 'round_to' to 'round_to const&' in these places:
  $ git grep 'round_to<\w*> *\w*;' *.hpp

I resisted the temptation to make that change for fear it would
interfere with special-member operations.