Cannot compare object.opEquals is not nogc

Sat Jul 23 19:17:27 PDT 2016

On Saturday, 23 July 2016 at 22:48:07 UTC, Lodovico Giaretta 
wrote:
> 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.

This just isn't right. What your saying is that because someone 
screwed up, we must live with the screw up and build everyone 
around the screw up. This mentality is why everyone is so screwed 
up in the first place, do you not see that?

And I think you really have a misconception about the GC vs nogc. 
One can rewrite GC code, such as an GC based opEquals, without 
limitations. They can allocate on the stack, use malloc and free 
when done, etc. opEquals generally doesn't have state. So you it 
is possible to around around. It's probably always possible to 
rewrite a GC opEquals to use nogc without too much difficulty.

BUT, it is impossible to use a GC opEquals in nogc code! This 
means there is no work around. What you claim is that we accept 
the impossiblity(which makes nogc useless) just to avoid having 
to rewrite some GC opEquals code. We can't rewrite the nogc side, 
it's set in stone. We are screwed from the start when we attempt 
to do nogc code because at some point we will have to do 
comparisons. It's the same problem with purity and any other 
transitive relationship.

All "workarounds" are just as limited because basically we added 
the relationship if A is nogc and A uses B, then B must be nogc. 
Yet, we start with B is GC. Hence we never ever have A use B, 
because A's can only use nogc.

To see it simpler, What if everything in D was GC based. All code 
was marked GC(even statements, types, etc). Do you agree that 
nogc would be absolutely useless? We couldn't build up anything 
because we couldn't include any code. This is the extreme case.

Conversely, if everything was built up using nogc, we could write 
GC based code just fine, could we not?

Therefore, claiming that we stay with GC based code just prevents 
using more and more nogc code. The more GC based code D gets, the 
less useful nogc gets and we are back were we started.

Since nogc is more critical in the foundational layers, as it 
affects everything built on it, all core features should be nogc. 
This way, the user isn't can decide when to break away from the 
GC code, which will only affect everything after that point.

This is a one way street, pretending it is two way only enriches 
the lawyers and eventually makes everyone unhappy. Making the D 
dependent on the GC was a mistake that many wasted man hours will 
go in to trying to unravel.  Trying to carry on this mistake just 
wastes more hours.

I understand that it is a mess, but it got that way from the 
mistake in the first place, not from trying to undo the 
mistake(which is illogical because there would be no nogc if 
there wasn't a gc in the first place).  I also understand that 
there is some desire to keep things "backwards compatible". This 
is also a mistake, not only does it prolong the pain and 
suffering but is irrational. 1. A fork can be made. Those people 
that have based their code on the GC can continue using an older 
version. Their code works at that point, does it not? So just 
stop going down that dead end path. They have what they need, 
it's not like they will lose anything(virtually nothing except in 
most cases). Moving in the correct direction is always better, 
regardless of who's panties get in a wad.