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