On Thu, 29 Sep 2011 09:32:06 -0400, Christophe
<trav...@phare.normalesup.org> wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:145729), a
I was arguing that opEquals (and co.) should *not* be const. IMO it
would be a huge problem if they were.
why? For what purpose do you need to change an object during
comparison?
You may not need to change the object, but you may need to call a
non-const method. It has been argued against the opponent to transitive
const that they are not obliged to use const. Then opEqual should not
oblige them to use const. const is so viral in D that people not willing
to use const will have to change lines and lines of code to get opEqual
working.
The argument that you are not obliged to use const is very hollow,
especially when it comes to Object. The reality is, whatever Object uses,
so must you use. There are no choices. Either Object is const-aware and
all your derivatives must be, or Object does not use const, and all your
derivatives must not. inout should make this much const more palatable,
when it gets implemented. But I think the right move is to make Object
const-aware.
For structs, I think you should be able to use whatever you want, there is
no base interface to implement.
It is always possible for a non-const version of opEqual to forward to
the const version, so people willing to use a const version do not have
to define a non-const version.
Again, you still need to define both, this is not a good situation.
-Steve
