I am not sure if I like this check. From a safety perspective it's better to return a const reference. The code you can write with a non-const reference is just weird.
What do you think.. should we remove this? Or move it to some addon perhaps?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The requirement for CopyAssignable require it to be a non-const reference. This could cause compile-errors when using this object with C++ algorithms since the standard algorithms can rely on this. Or this could compile but it would cause extra copies which can degrade performance.
Furthermore, with C++20 concepts, these requirements will be checked at compile-time when calling std:: functions in the future(using std::Assignable. So if your class' assignment operator returns a const-reference then you won't be able to use it at all with C++'s algorithms whether or not the implementation relies directly on the non-const reference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure if I like this check. From a safety perspective it's better to return a
const
reference. The code you can write with a non-const reference is just weird.What do you think.. should we remove this? Or move it to some addon perhaps?
The requirement for
CopyAssignable
require it to be a non-const reference. This could cause compile-errors when using this object with C++ algorithms since the standard algorithms can rely on this. Or this could compile but it would cause extra copies which can degrade performance.Furthermore, with C++20 concepts, these requirements will be checked at compile-time when calling
std::
functions in the future(usingstd::Assignable
. So if your class' assignment operator returns a const-reference then you won't be able to use it at all with C++'s algorithms whether or not the implementation relies directly on the non-const reference.ok you have convinced me that we should keep this check.