On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
