You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation says that drop will not be called for GC'd types - this is likely to lead to memory leaks, especially if the drop implementation has been automatically generated.
Another option would be to call destructors, but to make all access to GC'd fields panic at runtime if accessed from the destructor (essentially setting them to null before calling drop).
Then, finalizers could be re-purposed for destruction logic which actually requires access to GC'd fields (this would require some kind of resurrection support, like in .net)
The text was updated successfully, but these errors were encountered:
The readme gives only a brief overview of the situation and I think it has mislead you about why finalizers are necessary. There's a lot of ways this proposal is wrong - it misunderstands the problem and proposes an unworkable solution. I would write more here, but it would be quite long to explain and I intend to cover destructors in detail in the blog series so I'm going to avoid repeating myself. Stay tuned :)
The documentation says that
drop
will not be called for GC'd types - this is likely to lead to memory leaks, especially if the drop implementation has been automatically generated.Another option would be to call destructors, but to make all access to GC'd fields panic at runtime if accessed from the destructor (essentially setting them to null before calling drop).
Then, finalizers could be re-purposed for destruction logic which actually requires access to GC'd fields (this would require some kind of resurrection support, like in .net)
The text was updated successfully, but these errors were encountered: