Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It would be nice if this explained how to deal with data structures containing cycles. Want to solve a Traveling Salesman problem? Each city object would logically have pointers to neighbors. Multiple pointers to each city, no clear rule for which ones own which others, cycles everywhere. Yes, you can solve this by putting the owning pointers into an array and using indices elsewhere, or similar tricks, but that still leaves you prone to leaks. It's easy to get memory safety - no use after free, buffer overflow, etc. - if you don't care about leaks. The real trick is to come up with something that's also provably leak-free even in the presence of cycles.


This should work just fine in Vale, instead what will happen is once you delete a city, and you try to access it from another city through a reference, your program will panic.

Generational references are nothing new, they are often used whenever you have an object pool. The novelty is in applying them to the whole program, effectively turning use-after-free into an out-of-bounds panic of sorts.


I'm not sure that "it's possible for your program to do this thing and if it does the program will panic" really qualifies as memory-safe. Maybe it's better than what you'd get in C, but in some kinds of programs it could still be a DoS vector. In a garbage-collected language or unsafe-free Rust it would not be possible to crash because of a deleted city, and that would be strictly better.


The vast majority of rust application code has unwrap()s everywhere, not to mention bounds checks on arrays, both of which trigger panics.

You can always check the validity of a generational reference before every use, just as you can check the array length or the Result<T,E>




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

Search: