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.
