Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

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.
     - we must have @nogc (or @whatever): then we know we cannot 
use certain classes, because they are definitely @nogc; so we 
cast the objects we get to the classes/interfaces that we know 
are @nogc (and are marked as such), and then our code is @nogc; 
as you see, you don't need Object to have @nogc methods; you only 
need the specific classes you use have it; if you want to work on 
generic objects, and as such cannot do specific casts, then you 
should definitely be using templates.

The only real problems I found till now are:
- some things in Phobos that shall be @nogc are not; they shall 
be refactored to have that attribute (but this is not always easy 
and requires time)
- the interface IAllocator is mostly used with @nogc allocators, 
but cannot have the said attribute (as I explained above, it must 
not restrict the possibility of allocators); it shall have a 
sub-interface NoGCAllocator, so that code can accept a @nogc 
allocator parameter without using templates (of course templates 
are fine, and are what we use now, but if everyone uses 
templates, why have IAllocator in the first place? IMHO we must 
have or both or none).