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

I don't see the problem with returning immediately after borrowing a reference, if the scheduler lives shorter than the results (if it doesn't, holding the reference would be unsound): https://play.rust-lang.org/?gist=226f92bc311dbac05c112b10ba4...



You're exclusively borrowing res_a, res_b and res_c for the lifetime of the scheduler. Which works fine since res_a, res_b and res_c are hard-coded variables with separate lifetimes. What rust doesn't know how to do is borrow mutable references to elements of a container without borrowing the entire container.

https://play.rust-lang.org/?gist=1324a919ca5d0e2f16e445364a7...


This can be made to compile by using iterators: https://play.rust-lang.org/?gist=33d86898c4d16bf9bc9023a9c9a...

Rust also offers some other methods to allow multiple mutable references to containers: .split_mut() comes to mind – that splits a mutable slice into two mutable slices that don't overlap. In the future I'd like to see in the stdlib "container adapters" that take in a normal container and provide an interface to it that allows taking multiple mutable references while ensuring the soundness using dynamic checks (it can keep an array of the pointers or indexes that are borrowed out, and check against that). I created such an interface as an experiment last year: https://github.com/golddranks/multi_mut


The sibling comment shows how to do that in safe Rust code. But then, even when you have much more complex control that Rust compiler can not prove safety, you can still resort to unsafe, build your algo, and wrap it into a safe API, just like `split_at_mut`




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: