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

Reconsider T: Drop #7

Closed
bluss opened this issue Jan 13, 2017 · 1 comment
Closed

Reconsider T: Drop #7

bluss opened this issue Jan 13, 2017 · 1 comment

Comments

@bluss
Copy link

bluss commented Jan 13, 2017

Drop is not your usual trait. What does your bound do? It's probably not doing something sensible.

The Drop trait is used to hang destructors on types. Other types can have destructors without implementing Drop.

For example: String doesn't implement Drop, but it has a (structural) destructor that drops its fields (the Vec inside).

Another famous type that doesn't implement Drop is Box<T>...

@burdges
Copy link
Owner

burdges commented Jan 13, 2017

Interesting. I wrote ZeroDropDrop mostly as an exercise. In fact, I've no tests for ZeroDropDrop because I cannot currently imagine any use cases. If you want say a Vec to zero on drop, then you need either an allocator or a special data structure like cryptovec via #5 Anyways this sounds like enough reason to comment it out and put a warning. Thanks!

@burdges burdges closed this as completed Jan 13, 2017
burdges added a commit that referenced this issue Jan 13, 2017
I had my fun with ZeroDropDrop but there is no reason for it.
Actually zeroing drop data requires an allocator or custom type.

And @bluss observed that this type might be even more dangeorus
than I initially thoguht :
#7
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