Cannot compare object.opEquals is not nogc

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/23/16 5:44 PM, Rufus Smith wrote:
> On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta wrote:
>> On Saturday, 23 July 2016 at 17:04:42 UTC, Jonathan Marler wrote:
>>> On Saturday, 23 July 2016 at 16:46:20 UTC, Jonathan Marler wrote:
>>>> [...]
>>>
>>> Actually Im going to disagree with myself. This technique actually
>>> wouldn't work with virtual methods:)
>>
>> I don't think we have the big problems with @nogc that people points out.
>>
>> I mean, we cannot decide that specific methods or opXXX must always be
>> @nogc. That's too restrictive.
>>
>> So, what we need to do is:
>>
>> - use templates: with them, we can have our algorithms be @safe when
>> applied to @safe types, @nogc when applied to @nogc types, and so on;
>> for example, instead of taking a specific delegate type, we shall
>> always accept a generic type, and use traits to guarantee it is some
>> delegate; in this way, we can accept @safe delegate and propagate
>> @safety to our algorithm, or accept @system and have our algorithm
>> usable in @system code; same with @nogc et al.
>>
>> - when we use virtual methods, we are giving up all compiler-checked
>> attributes; in this situation we have two options:
>>     - 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. 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.

Again, I want to stress that Object.opEquals has been around since early 
D1 days, @nogc is only a few years old, it was not a wrong decision. 
@nogc cannot be added without breaking code, and even if you could, it's 
not correct for opEquals.

The issue is one of design, Object should not define which attributes 
are acceptable on all objects, that should be up to the class designer. 
The solution is to deprecate and remove all convenience functions from 
Object.

> DMD should probably be branched, and all GC stuff removed, then built
> back up to have the proper features that the GC version has. I think
> someone has essentially done this on their own, but never built it up to
> full capacity.

This is an extreme solution for a minor problem.

-Steve