Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

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.

If, say, D was built without the GC, then adding the GC would be 
much easier and more logical than what has been done, which is 
built with GC and trying to remove it.

>     - 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).

Templates are not the end all be all. They don't allow for 
run-time polymorphism, which is an important aspect of software. 
What we should have is that when something is added or removed we 
are 100%(or close as we can get) that the feature is correct and 
causes no side effects. D's GC causes side effects because it was 
assumed that there would not be any.  Now the future is hear and 
it's up to us to try and unravel the mess the past created. It's 
always best to just do it right in the first place, it saves 
everyone from the headache.

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.