Cannot compare object.opEquals is not nogc

[Jonathan Marler via Digitalmars-d-learn]

On Sunday, 24 July 2016 at 15:41:55 UTC, Lodovico Giaretta wrote:
> On Sunday, 24 July 2016 at 15:28:53 UTC, Jonathan Marler wrote:
>> 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?
>
> Currently, you cannot. Everything inherits from Object. I 
> personally think this is not the best idea. But it's not that 
> horrible either, so probably not worth a big change.
>
> But you can just ignore it. You can put on your opCmp all the 
> attributes you want and forget about it inheriting from Object. 
> You can decide to never write a method that takes Object. 
> Always take the root of your sub-hierarchy, so that you know 
> what attributes you have.
> If it derives from Object or not, nobody cares as long as your 
> sub-root overrides all opXXX with new (even abstract) 
> declarations that have @nogc.

This is one of those problems that are going to have pros and 
cons either way you go. It's the balance between generality which 
yields facilities for sharing code, and specificity which 
inhibits shared code.  Templates provide an interesting middle 
ground for this by allowing you to instantiate an infinite number 
of implementations that will fit wherever you want on this 
spectrum.  But templates don't work with virtual methods :(

Just spitballing here, but why weren't the methods on the Object 
class defined in interfaces instead?
   interface Hashable;
   interface Comparable;
   interface Stringable;

I'm sure there's some big drawback to designing it this way, but 
the reason is escaping me at the moment.  Can someone enlighten 
me?

(Note: if a feature like this 
(http://forum.dlang.org/post/mrtgipukmwrxbpayuqkt@forum.dlang.org) was implemented, the interfaces could still provide default implementations)