On Wednesday, 2 January 2013 at 09:07:31 UTC, monarch_dodra wrote:
My opinion is that supporting non-const opEquals makes no real
sense, and adds a lot of useless complexity (and inconsistency)
to the code. At best, it means silently accepting erroneous
code... Until it explodes in someone else's face...
If the code doesn't change anything, it should be const.
I know in a sorting algorithmn I am testing with I created a
struct that held three numbers. The comparing number, and
ordering number (to check against stable sorting) and a counter
for how many times that number was compared against. So there
could be uses for non-const versions, but those shouldn't affect
the rest of the library for a few use cases.
