Cannot compare object.opEquals is not nogc

[Jonathan Marler via Digitalmars-d-learn]

On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote:
> Remember that comparison of complex objects may require 
> normalization, which may change the objects themselves and 
> allocate memory.

Sure but this case will be the exception.  If an application 
really needs this they can implement their own normalizedEquals?  
It wouldn't work with the comparison operators, but I don't 
really like to use those comparison operators for classes anyway 
since they do waaay to much in most cases:

https://github.com/dlang/druntime/blob/master/src/object.d#L136

auto opEquals(Object lhs, Object rhs)
{
     // If aliased to the same object or both null => equal
     if (lhs is rhs) return true;

     // If either is null => non-equal
     if (lhs is null || rhs is null) return false;

     // If same exact type => one call to method opEquals
     if (typeid(lhs) is typeid(rhs) ||
         !__ctfe && typeid(lhs).opEquals(typeid(rhs)))
             /* CTFE doesn't like typeid much. 'is' works, but 
opEquals doesn't
             (issue 7147). But CTFE also guarantees that equal 
TypeInfos are
             always identical. So, no opEquals needed during CTFE. 
*/
     {
         return lhs.opEquals(rhs);
     }

     // General case => symmetric calls to method opEquals
     return lhs.opEquals(rhs) && rhs.opEquals(lhs);
}

> ...Also, comparisons may throw exceptions that need the GC (see 
> above). So I'm personally against making those methods @nogc.


Definitely true. One thing to note is that toHash is nothrow. 
Whether or not this is too restrictive is definitely up for 
debate, but also making opCmp/opEquals nothrow wouldn't be the 
worst thing in the world.  Of course at this point, it would 
likely break ALOT of code, so probably not worth it pragmatically.

>
> But I'm also against a singly-rooted hierarchy. Removing Object 
> and having multiple class hierarchies would entirely solve the 
> issue. But please note that you can already "do" that: if you 
> never use Object, but always subclasses, the fact that Object 
> isn't @nogc is no longer an issue.

Whoa wait a second...I didn't know you could do this.  I thought 
everything had to inherit from the object class.  Can you share 
the syntax to define a class that doesn't derive from object?

P.S.

Talking about throwing exceptions in @nogc is preaching to the 
choir :)

https://forum.dlang.org/post/ubtlemuqisxluxftsrks@forum.dlang.org

I've explored this issue as well, I came up with a way to throw 
exceptions allocated on the NonGC heap, but to clean up memory 
the catcher needs to do something to dereference the exception so 
it gets cleaned up.  There is a DIP for natively supporting 
reference counted memory, I don't remember it, but it would allow 
such things to be safe to use.