I think it’s more of a time vs code tradeoff, if done properly.

For example in the Vec case, you could theoretically build an alternative which encodes the “three sections” property internally, and ensures correctness at construction time for the pointers. Not as completely safe as a Vec, but you can still get similar benefits for the “business logic”.

But I agree, just having a custom structure that does not provide a safe wrapper around this would be sacrificing standard guarantees.

You can make a wrapper type that abstracts the offset lookup logic with a safe interface. If it's a transparent struct then rust will compile it away into nothing but you still get the abstraction in your code.

> I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees.

Not really. You just need to make the underlying fields private and provide methods to get slices to the data you need.

you could always do a .get into the vector and handle the error, it doesn't necessarily need to panic.

Thank being said in this case it should be impossible to index out of bounds so maybe a panic is warented.

It's the exact thing Rust is made to protect against, on a more local scale. Every memory corruption bug is just an out-of-bounds index that wasn't protected against.

Tools exist to serve us, not the other way around.