←back to thread

Tree Borrows

(plf.inf.ethz.ch)
565 points zdw | 2 comments | | HN request time: 0.001s | source
Show context
fuhsnn ◴[] No.44512042[source]
I wonder if Rust or future PL would evolve into allowing multiple borrow checker implementations with varying characteristics (compile speed, runtime speed, algorithm flexibility, etc.) that projects can choose from.
replies(9): >>44512293 #>>44512361 #>>44512426 #>>44512597 #>>44512841 #>>44513554 #>>44513949 #>>44516880 #>>44516995 #
0x000xca0xfe ◴[] No.44512597[source]
As I understand it the borrow checker only has false negatives but no false positives, correct?

Maybe a dumb question but couldn't you just run multiple implementations in parallel threads and whichever finishes first with a positive result wins?

replies(2): >>44512965 #>>44517616 #
1. creata ◴[] No.44517616{3}[source]
> As I understand it the borrow checker only has false negatives but no false positives, correct?

The borrow checker is supposed to be a sound static analysis, yes. I think Ralf Jung's comment at https://news.ycombinator.com/item?id=44511416 says soundness hasn't been proved relative to tree borrows yet.

> Maybe a dumb question but couldn't you just run multiple implementations in parallel threads and whichever finishes first with a positive result wins?

IIUC when you're compiling reasonably-sized programs you're already using all the cores, so parallelizing here doesn't seem like it's going to net you much gain, especially if it means you're doing a lot of extra work.

replies(1): >>44518971 #
2. 0x000xca0xfe ◴[] No.44518971[source]
Thanks, didn't see that!

> when you're compiling reasonably-sized programs you're already using all the cores

Only on full rebuilds. I would assume most build jobs with a human in the loop only compile a handful of crates at once.

In fact as CPUs get more and more parallel we'll cross the threshold where thread count surpasses work items more often and then will come the time to get creative ;)