Hacker News Reader

Comment by khyryk | Hacker News Reader

Certainly looking forward to the borrow checker improvements as it's quite tedious to work around the match borrowing problem.

View on HN

What's interesting to me about SEME regions/non-lexical borrows is that it's a great example of a tradeoff:

Right now, the borrow checker's rules are very straightforward: references live for the entire lexical scope that they're alive. However, the downside of this is that sometimes you want the scope to end early, and so you have to code around it.

With non-lexical borrows, the rules get much more complex: borrows are determined by the control flow graph, not lexical scope. However, you no longer need to code around those edge cases.

So the question of which is better really comes down to a question: do programmers find reasoning about lexical scope or the CFG more intuitive? It would appear the latter is the case, which is kind of surprising for me, but maybe it shouldn't be.

Can't you think of it as still being scoped - just more fine grained? Pieces of structs can be borrow checked (what you are using) instead of the whole struct?

Yes, it's a scope, but not a lexical scope, hence the name :)

I believe that 'borrowing part of a struct' is a different extension to the system, actually, though maybe they'll be put together. I haven't been involved in the pre-RFC myself.

We already do that. (See LoanPath in the compiler.) It's not a problem of reasoning about the structure of data--it's a problem of defining a notion of "overlapping control flow regions" that is simultaneously intuitive to the programmer, easy to compute, sound, and satisfies the ordering constraints we need (well-defined GLB, LUB, and partial order).

Is there a real trade off between intuitive and easy to compute, versus sound and satisfies the ordering constraints, or can you just compute the most precise sound solution?

Maybe; it's unclear. The hardest part is getting the GLB/LUB/subtyping right.

Remember that Rust CFGs are much simpler than C++ CFGs (no goto, for one), and in general CFG analysis is simpler due to ownership. It's easier to reason about Rust control flow than it is about C++.

Same here, the borrow checker in it's current incarnation left a sour taste in my mouth. What made it worse, the language market keeps plugging the borrow checker as this great fully baked feature. And (like you said) in real life it's fairly easy to run into cases where the borrow checker has false positive that are hard to work around.

I was disheartening to see what it was not a priority to tackle it. There's long standing bugs (2+ years) filed in github against it. And so far the answer has been it's hard to fix this, so we're not going to do it yet.

I'm really happy to this development. I hope this is sooner rather then later (have to wait to 2016)

Reply on news.ycombinator.com