0

When declaring assignment operations as default, is there anything wrong to make them reference qualified to prevent assignment to temporaries? (Most often than not, it prevents stupid errors). Common resources, do not say anything about reference qualifiers for "default" operations, and almost every example I've seen so far, doesn't declare them with proper ref-qualifier.

Does language standard say anything about reference qualifiers declaring assignment operations as default.

  1. It is allowed?
  2. Is there anything wrong about doing that? After all, with very few exceptions, assigning to rvalues doesn't make sense.
  3. I understand that they were not made reference qualified by default for backwards compatibility, however is there a reason not to that? (In case that the answer to first question is "yes" and the answer to the second one is "no").
Myrddin Krustowski
  • 701
  • 3
  • 13
  • 2
    A few minutes with a C++ compiler should easily tell you if it compiles, or not, which will tell you if it's "allowed"; is there something that's preventing you from simply determining this yourself? As far as whether there's anything "wrong about doing that", just like everything else in C++, it's maybe right, or wrong, depending on the particular details of each case. There is no C++ authority, of some kind, that issues decrees about something unilaterally being wrong, or not. – Sam Varshavchik Nov 10 '22 at 11:44
  • Compiler accepting code doesn't rule out UB. I have no reason to believe that it would be UB, but who knows these days... – Myrddin Krustowski Nov 10 '22 at 11:46
  • Function qualifiers and if the functions can be called is about compiler-checked syntax and semantics. – Some programmer dude Nov 10 '22 at 12:32
  • If it is generated by all the compilers, does the standard guarantee that it is the way it should be? For example, copy operations are usually generated even in cases deprecated by the standard. – Myrddin Krustowski Nov 10 '22 at 12:55
  • 1
    A mere declaration, by itself, cannot be UB. Depending on what the code does, that can be UB, but a ref-qualified operator overload is as much UB as `int x;`. – Sam Varshavchik Nov 10 '22 at 13:10
  • As far as I understand the wording, technically `A& operator=(const A&) = defualt` is not a declaration, but a definition. It might fail, in some cases it might fail - for example if we provide a signature not expected by the compiler , such as wrong result type of const/volatile qualification, or wrong argument (such as `A` instead of `const A&` or `const A&&` instead of `A&&`). Sometimes it doesn't - for example when providing ref-qualifiers or declaring argument as reference instead of const reference. My question is whether standard requires generation of the ref qualified version or not – Myrddin Krustowski Nov 10 '22 at 14:33

1 Answers1

1

It is allowed to define a defaulted assignment operator with an additional ref-qualifier. See [dcl.fct.def.default]/2.1.

Whether or not you should actually do it is an opinion-based question. I don't see anything obviously wrong with adding a &, but I suspect that you'll encounter resistance if you try to convince everyone on your team to do it, because it may indeed catch some bugs, but very few, and almost all of those bugs are likely to be inside unit tests anyway. (In contrast, bugs like if (x = 3), where the left side is an lvalue, are much more common, and you won't catch those, but maybe the compiler will issue a warning.)

It's sort of like how you might have trouble convincing people to declare their const char* variables as const char* const if they know the pointer isn't going to change. Sure, it increases safety by a bit, but it also requires extra typing.

Brian Bi
  • 111,498
  • 10
  • 176
  • 312