[dxhdr]

It's essentially a "user-space" memory allocator with it's own use-after-free and double-free checks, apparently because the language implementation isn't adequate. If anything it just reinforces the articles point that "borrow checking is incompatible with some useful patterns and optimizations."

[junon]

Eh? This is a wild take. How do you draw the conclusion the default implementation is inadequate?

[dymk]

Because something like slotmap has to use `unsafe` to get around the inadequacies of the borrow checker...

[orlp]

Author of slotmap here.

There is absolutely no need for unsafe in slotmap. I chose to use unsafe (wrapped in a safe API) to reduce memory usage using intrusive linked freelists. If done using safe Rust this would involve `enum`s that would take up extra space.

[junon]

Slotmap is one of my favorite crates, by the way. Thank you for putting it out there!

[pjmlp]

Thus not adequate for performance requirements.

[junon]

.... that has nothing to do with the allocator though

[burntsushi]

A downside for sure, but one that, at least in this specific example, has limited downsides. If you can button it up into a safe abstraction that you can share with others, then I don't really see what the huge problem is. The fact that you might need to write `unsafe` inside of a well optimized data structure isn't a weakness of Rust, it's the entire point: you use it to encapsulate an unsafe core within a safe interface. The standard library is full of these things.

Now if you're trying to do something that you can't button up into a safe abstraction for others to use, then that's a different story.