Hacker News new | past | comments | ask | show | jobs | submit login

I feel like the "Store an index to get around the borrow checker" largely moves the problem - now you have A) array-bounds-checking bugs, and B) either "list was re-ordered, you now have the wrong item" or "can't compact the list, it just keeps growing even when old items are no longer used" bugs.

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.




> 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-in...


Yes, 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: