Required constness of opEquals (and opCmp) ?

monarch_dodra monarchdodra at gmail.com
Wed Jan 2 01:07:30 PST 2013


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/urzkfsaqvodhhcnqeoet@forum.dlang.org

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?


More information about the Digitalmars-d mailing list