3 ms·
> array-bounds-checking bugs. Rust tries very very hard to avoid bounds-checking bugs, because it's central to the safety promise, maybe I'm misunderstanding y
by davidatbu 3y ago
> array-bounds-checking bugs.
Rust tries very very hard to avoid bounds-checking bugs, because it's central to the safety promise, maybe I'm misunderstanding you?
> either "list was re-ordered, you now have the wrong item" ... "can't compact the list, it just keeps growing even when old items are no longer used" bugs.
I have no direct experience implementing this pattern, but it's good to know that leptos (and others) tend to use one well-tested library that addresses these concerns[1].
> Sure, you no longer have to satisfy the borrow checker - but it was a tool to help you catch bugs, and you've cleverly avoided getting that help.
My impression is that one can perhaps claim "one traded compile-time checks of safety for runtime _panics_ when unsafe things are about to happen", and not that using this pattern exposes one to the same issues that the borrow checker avoids.
[1] https://docs.rs/slotmap/latest/slotmap/index.html#why-not-index-a-vec-or-use-slab-stable-vec-etc https://docs.rs/slotmap/latest/slotmap/index.html#why-not-in...
- danielheath 3y agoYes, the failure here is a panic, typically a crash (of at least the affected subsystem), not memory corruption. Slotmap avoids this via unsafe + implements its own handle system, which is probably the right approach. The borrow checker avoids many other issues in addition to memory safety.