One thing people (like me ) often say is that it forces you to “learn to write better.”
One way you can think of it is this:
- Rust rejects some programs that are truly wrong (`“2” + 3` style)
- Rust rejects some programs that really are just fine. They are actively improving this with stuff like “Non-lexical lifetimes.”
- Rust rejects some programs that are fine _how they are now_, but which are hard to keep fine when you change them. This is part of why linked lists are hard to write in Rust :-)
I admit that I'm very unexcited about non-lexical lifetimes—the cost-to-benefit ratio seems worse than the current model. The current lifetime system is simple to understand: a value is live until its owning variable goes out of scope. It can be a bit restrictive sometimes (though it seems that after a while you learn how to work around those issues easily enough), but it's easy to keep in your head and reason about code. With non-lexical lifetimes, I think that we'll have a harder time understanding lifetimes, it'll be more difficult to teach them and to debug them.
My understanding is that the semantics are exactly the same, but it’s just possible for the checker to match your intent more tightly.
For example, in lexical lifetimes, this fails:
let x = &mut foo;
if x.bar() {
baz()
} else {
foo.consume() // takes foo by value
}
It will complain that you’ve used `foo` while it is borrowed by `x`, even though a human can easily tell that `x` is already irrelevant by that point. NLL would accept this (I believe).
One way you can think of it is this:
- Rust rejects some programs that are truly wrong (`“2” + 3` style)
- Rust rejects some programs that really are just fine. They are actively improving this with stuff like “Non-lexical lifetimes.”
- Rust rejects some programs that are fine _how they are now_, but which are hard to keep fine when you change them. This is part of why linked lists are hard to write in Rust :-)