On Wednesday, January 02, 2013 10:07:30 monarch_dodra wrote: > 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?
This has been discussed quite a bit with regards to classes. We need to be able to support both const and non-const versions of opEquals, opCmp, toHash, and toString. D's const is restrictive enough that it prevents stuff like caching and lazy loading from working properly with const, meaning that we _cannot_ require const. Yes, in most cases, opEquals should be const, but it can't always be, so we can't assume that it is. However, there's a good chance that inout could be used instead if you're worried about duplicating code. - Jonathan M Davis
