opEquals the template?

[Steven Schveighoffer]

There is a debate in a sub-thread about logical const on whether  
Object.opEquals should be const or mutable.

Right now, it's mutable.  This disallows comparison between const objects  
(except it is technically allowed because the compiler ignores const  
correctness for this).

I think it should be const.

However, making it const disallows opEquals functions which mutate the  
object (for lazy loading or caching purposes).  I question that this is a  
major concern, but I have discovered an easy fix that appeases all.

If we make opEquals a template (not Object.opEquals, but the free function  
opEquals(Object lhs, Object rhs) ), then the template has access to the  
full type information of the derived object.  This means that  
Object.opEquals can be exclusively const, and you can overload this with a  
mutable version, and everything just works.

I tried it out by making my copy of druntime use a template (it's actually  
very few lines change).  Although I needed to use casts to compile some  
parts of phobos (some opEquals calls depend on the compiler ignoring const  
guarantees as mentioned above), when compiling a simple test program, I  
can prove it works without compiler changes.

Along with the ability to have both const and non-const (and even  
technically immutable) opEquals, we have the following drawbacks and  
benefits:

1. template bloat.  Every combination of two object types being compared  
will generate a new template.
2. inlining of opEquals.  Both the free function template, and possibly a  
final-declared opEquals on a dervied object could be inlined.
3. possible specialization of opEquals(MyDerivedType obj).  I don't  
remember exactly the overloading rules, so this may be impossible.
4. Fixes the issue with interface comparison (see bug  
http://d.puremagic.com/issues/show_bug.cgi?id=4088), not in the best way,  
but it would be better than the current situation.

What do people think?

-Steve