Cannot compare object.opEquals is not nogc

[Jonathan Marler via Digitalmars-d-learn]

On Sunday, 24 July 2016 at 09:03:04 UTC, Lodovico Giaretta wrote:
> On Sunday, 24 July 2016 at 02:17:27 UTC, Rufus Smith wrote:
>> [...]
>
> Now you are telling me to "program by trust", because there's 
> nothing ensuring that I remember to free everything I allocated 
> with malloc/free, while a GC would guarantee no memory leaks. 
> Again there's nothing stopping me from returning pointers to 
> things allocated on the stack. And now there are lots...
> Before you told me that programming by trust is a wrong 
> attitude, and now you propose me to use it, risking memory 
> leakage in a function that may be executed hundreds of times 
> per second.
>
>> [...]
>
> No. If you put a big @nogc attribute on Object.opXXX, then 
> nobody can write GC code in his classes. So if everything is 
> @nogc, you cannont write GC code, because it woudn't interact 
> with Phobos. Example: if you mark an algorithm that takes a 
> delegate @nogc, then you cannot pass GC delegates to it. So you 
> cannot use it in GC code.
>
>> [...]
>
> Yes. All building blocks must be as much @nogc as possible. But 
> customization points (virtual functions, delegate arguments, 
> ...) must not be @nogc, otherwise it is no possible to have 
> classes that use the GC or callbacks that use the GC.
>
>> [...]
>
> I still don't understand why you want Object.opXXX @nogc. As I 
> already said, you can still make your functions @nogc, just 
> accepting parameters of @nogc types. It's obvious. If I wrote a 
> wonderful library that uses the GC, you will not use it. If I 
> have a class that uses the GC in opXXX (and I am free to have 
> it, because maybe I need it, and maybe it's the most efficient 
> way for my use case), you will not use it. The same applies 
> here. You'll have your algorithms work only on classes that 
> declare opXXX as @nogc.
>
> Not all memory allocation patterns are good for malloc/free. 
> Not all of them are good for stack allocations. Some of them 
> are not even good for reference counting. Every class shall use 
> the best solution for its job. And everybody must still be able 
> to extend the base class.
> If you want to use a method specific to a subclass, you 
> downcast. If you want to use the @nogc opXXX when the base does 
> not enforce it, you downcast. It's the same principle: more 
> advanced functionalities require more derived types (and @nogc 
> is more derived, because it is covariant to not- at nogc). Basic 
> OOP.

I believe Rufus was only referring to the virtual methods defined 
in the object class.  That would be:

toHash (Note: this is already nothrow, that's intersting and 
quite restrictive)
opCmp
opEquals

I think all 3 of these are good candidates for @nogc.  However, 
AFAIK, making them @nogc would break any code that implements 
them because they would have to add the @nogc attribute to their 
implementations (unless I am mistaken?  Do subclass overrides 
need to explicitly have @nogc if the parent class does?).  If 
adding @nogc is not required in the implementation, then the only 
code that would break would be implementations that actually do 
allocate GC memory.

Some would think that restricting GC usage inside these virtual 
methods is a good thing because it has the benefit of 
discouraging memory allocation for these types of operations.  
Really, you probably shouldn't be allocating memory to perform a 
comparison.  If you really need to, you can either allocate non 
GC memory, or use a different mechanism then the opCmp/opEquals 
methods.