How can I save a class use the RedBlackTree?

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 03, 2016 13:26:22 Meta via Digitalmars-d-learn wrote:
> On Tuesday, 3 May 2016 at 12:12:04 UTC, Jonathan M Davis wrote:
> > On Tue, 3 May 2016 11:37:13 +0200
> > Steven Schveighoffer via Digitalmars-d-learn
> >
> > <digitalmars-d-learn at puremagic.com> wrote:
> >> bleh, Object.opCmp only works with mutable objects. Which
> >> means RedBlackTree cannot work with objects because it uses
> >> inout to ensure your objects are not modified (since 2.068)
> >>
> >> It doesn't work with const or immutable either, the only
> >> possible solution is to go back to mutable only.
> >>
> >> So annoying, we need to fix Object.opCmp, or using
> >> const/immutable comparisons with objects doesn't work.
> >
> > Hopefully someday...
> >
> > https://issues.dlang.org/show_bug.cgi?id=9770
> >
> > - Jonathan M Davis
>
> What's stopping us right now from making opCmp a free function in
> object.d?

In general, the two big blockers for removing opEquals, opCmp, toString, and
toHash from Object are

1. The built-in AAs either need to be fixed so that they don't need Object
and use the actual type that you're telling them to use (e.g. by
templatizing them internally), or using classes as keys in the built-in AAs
needs to be deprecated. The first requires fixing the built-in AAs, which is
a huge pain. There have been several attempts, but AFAIK, no one has ever
succeeded (Martin was the last one to try from what I recall, but I don't
know how far he got). The second requires that we have a proper replacement
in Phobos so that folks would actually have an alternative when using
classes as keys was deprecated. At some point here, we're going to need to
decide whether it's actually feasible to fix the built-in AAs, or whether we
should just reduce what they can do to the sane subset, but it doesn't
necessarily matter much as long as we don't have a viable HashMap/HashTable
implementation in Phobos.

2. One or more compiler devs have to be convinced to prioritize making the
changes required to actually deprecate these functions without breaking code
(which isn't exactly straightforward). And we haven't even worked out yet
exactly how such deprecations would work. It would be trivial if we could
just break code, and the changes required in programmers are likely to be
minor, but immediately breaking code like that without a deprecation path is
not acceptable.

As for making opCmp a free function, that's not how operator overloading
works. The fact that opEquals ends up using a free function to call the
opEquals on your type is an anomally (it's required for opEquals because of
communutativity concerns). It _might_ make sense for opCmp for the same
reasons but only if opCmp is required to have strict ordering (which is a
matter of some debate).  But even if it did make sense to turn opCmp into a
free function, making that work rather than just creating a free function
called opCmp that never gets used by anything would likely require effort
similar to (or worse than) what would be required to make it possible to
cleanly deprecate opCmp on Object.

The first concern is sorting out what we do with the built-in AAs, which is
potentially blocked by Andrei's revamping of std.container so that we can
have a proper HashMap/HashTable in Phobos. The second concern is then
figuring out the best way to go about actually deprecating those 4 functions
and getting someone to do it. I expect that it will happen, but it's blocked
by some stuff that could take a while, and it hasn't been a high priority.

- Jonathan M Davis