Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 21:44:05 UTC, Rufus Smith wrote:
> On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta 
> wrote:
>>     - we trust what we are doing: e.g. we cannot mark a thing 
>> @nogc, but we know it is and the profiler confirms that no 
>> allocation happens, so we are happy; our aim is having code 
>> that doesn't freeze because of collections, and not marking 
>> code @nogc.
>
> This is bad. It only creates a faulty foundation. The whole 
> point of nogc is to enforce nogc behavior. If you don't use it 
> your not enforcing anything and then things slip by only to 
> create problems later. This mentality is completely wrong and 
> leads to decay.

While you are right on this, we must be pragmatical: we currently 
do not enforce that pointers point to valid memory locations, 
that private members are not accessed outside the module with 
tricky arithmetics, we have tons of things that work by 
convention, because the compiler simply can't check them all and 
some are even intrinsically uncheckable. In this environment of 
"code by trust", @nogc is the least of the problems, also 
because, I insist, it can be checked with the profiler, or you 
can plug a custom GC to druntime that asserts every time you try 
to call its functions (work is being made to make the GC 
independent and pluggable).

> This is exactly why we are discussing this right now, because 
> someone decided that it was ok to ignore other use cases which 
> eventually turn out to be quite important.

Well, I think that deciding that opXXX must always be @nogc, 
ignoring other use cases that may need the GC, is blatantly 
wrong. By asking that Object.opXXX be @nogc, you are making the 
error the error you said others made.