All right, all right! Interim decision regarding qualified Object methods

[Steven Schveighoffer]

On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> You destroyed, we listened.
>
> I think Christophe makes a great point. We've been all thinking inside  
> the box but we should question the very existence of the box. Once the  
> necessity of opCmp, opEquals, toHash, toString is being debated, we get  
> to some interesting points:
>
> 1. Polymorphic comparisons for objects has problems even without  
> considering interaction with qualifiers. I wrote quite a few pages about  
> that in TDPL, which add to a lore grown within the Java community.

yes, this is why we have the weird situation of object.opEquals.  I'd like  
to get rid of that at the same time, or at least make it super-simple.

> 2. C++ has very, very successfully avoided the necessity of planting  
> polymorphic comparisons in base classes by use of templates. The issue  
> is template code bloat. My impression from being in touch with the C++  
> community for a long time is that virtually nobody even talks about code  
> bloat anymore. For whatever combination of industry and market forces,  
> it's just not an issue anymore.

But C++ has no base object whatsoever!  I don't think it's a fair  
comparison.

Template bloat for small wrappers is almost non-existent (yes, the symbols  
are still generated) when the wrappers call virtual functions.  I don't  
think this is an issue.

> 3. opCmp, opEquals, and toHash are all needed primarily for one thing:  
> built-in hashes. (There's also use of them in the moribund .sort  
> method.) The thing is, the design of built-in hashes predates the  
> existence of templates. There are reasons to move to generic-based  
> hashes instead of today's runtime hashes (such as the phenomenal success  
> of templated containers in C++), so it can be argued that opCmp,  
> opEquals, and toHash exist for reasons that are going extinct.

Yes.  Where's that new AA struct, Mr. Teoh? :)

> 4. Adding support for the likes of logical constness is possible, but  
> gravitates between too lax and onerously complicated. Walter and I don't  
> think the aggravation is justified.

Removing those functions removes logical const as a solution, but does not  
invalidate the need for logical const.  For example, it still would be  
useful to have a logical const for objects that are stored across a  
connection.

> What say you?

I think this is the right approach.  I always found (even since D1 days)  
Object.opCmp and opEquals to be very awkward, especially how you must  
implement the derivatives (it's much more straightforward to say  
specifically what objects you can compare against, vs. always having to  
cast from Object).

Nuke 'em.

-Steve