Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop/Finalizers #3

Open
Diggsey opened this issue Oct 17, 2018 · 1 comment
Open

Drop/Finalizers #3

Diggsey opened this issue Oct 17, 2018 · 1 comment

Comments

@Diggsey
Copy link

Diggsey commented Oct 17, 2018

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)

@withoutboats
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants