Live data from Hacker News

Allocgate: Restructuring how allocators work in Zig

pithlessly.github.io

51–52 of 52 posts

Re: Allocgate: Restructuring how allocators work in Zig

#51
post #49

Earlier quoted context omitted.

However the Drop trait still has some safety issues, right? It appears to be more like Ada's Unchecked_Deallocation as it comes with some "use with care" footnotes. I remember reading something about it.

Not exactly, or at least, not in the same way as Unchecked_Deallocation. There are no memory safety issues with Drop. There are a few times when you need to be a little careful so that you don't get bad behavior: recursive Drop can stack overflow (which is caught and aborts), Drop while Dropping aborts which may not be what you want, if you've written unsafe code, you need to be careful with Drop because what is vali…

I see, then I misunderstood whatever was related to Drop and not being fully stable.

Yeah stack overflow can also be an issue on other RAII approaches.

Re: Allocgate: Restructuring how allocators work in Zig

#52
post #51

Earlier quoted context omitted.

Not exactly, or at least, not in the same way as Unchecked_Deallocation. There are no memory safety issues with Drop. There are a few times when you need to be a little careful so that you don't get bad behavior: recursive Drop can stack overflow (which is caught and aborts), Drop while Dropping aborts which may not be what you want, if you've written unsafe code, you need to be careful with Drop because what is vali…

I see, then I misunderstood whatever was related to Drop and not being fully stable. Yeah stack overflow can also be an issue on other RAII approaches.

Hm yeah, on the "not fully stable" angle, there's also some talk about "async drop," which doesn't exist just yet, and would be useful in async contexts. Maybe that's what it was.
Post reply on HN