I was wondering: Does Phobos require that user defined opEquals (and opCmp) be const?

If someone wants to define a non-const opAssign, I'd say that's their problem, but are we (phobos) expected to support it?

The reason I ask is because adding support for this means that every type that wraps any other type (which is basically... everything), would be required to implement *two* signatures for opAssign. Not only that, they'd both have to be conditionally implemented...

The context of this question is:
http://forum.dlang.org/thread/[email protected]

Basically, a DList of tuples: Problem:
DList has a "const correct" opEquals, but Tuple's isn't. It has:
//----
bool opEquals(R)(R rhs);       //1
bool opEquals(R)(R rhs) const; //2
//----

The problem is that //2 should really be:
//----
bool opEquals(R)(const R rhs) const; //2
//----

However, my question is: Should we even provide //1 at all? Is it fine if I deprecate this signature?

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...

Opinions?

Reply via email to