Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Newcomers to Rust often find that the borrow checker _always_ stands in their way, because they haven't internalized the rules yet. I've also spoken with a few frustrated ex-C++ers, who have some sort of pet pattern that works basically all the time, but the borrow checker doesn't like the 'basically.'

Another good example is that the borrow checker is currently based on lexical scope. See all the examples in https://github.com/rust-lang/rust/issues/6393 .

In general, any kind of analysis like the borrow checker will reject some valid programs, as it pays to be extra conservative. You then slowly expand the set of accepted programs, until hopefully, it matches the true set of valid programs, without accepting invalid ones.

View on HN

> I've also spoken with a few frustrated ex-C++ers, who have some sort of pet pattern that works basically all the time, but the borrow checker doesn't like the 'basically.'

What kinds of pet patterns have you seen?

It's hard to remember specifics, as this is usually based off of someone jumping into IRC and asking a question about how a certain thing works. They're often very detailed things that require intimate knowledge of implementation details. Or threads like http://www.reddit.com/r/rust/comments/31mgav/what_would_the_... , which isn't really _wrong_, but unions are hard, and so people miss them.

This kind of thing happens any time you transition languages: when I started hacking on Rust, I was trying to figure out how to do the metaprogramming shenanigans that Ruby lets me do. Ironically, Rust's metaprogramming features are my biggest weakness as a Rust programmer, I don't really write my own macros.

> In general, any kind of analysis like the borrow checker will reject some valid programs, as it pays to be extra conservative. You then slowly expand the set of accepted programs, until hopefully, it matches the true set of valid programs, without accepting invalid ones.

I'm wondering, is this possible in principle?

Context: I'm thinking in terms of sound-and-decidable type-checking conservativeness [0], but perhaps that's a bad way of thinking about this? Perhaps borrow-checking is a special-enough case of type-checking that somehow isn't afflicted by this (how?) or gives up the soundness (does it?)?

[0] "A sound type system with decidable type-checking (and possibly decidable type inference) must be conservative." -- http://gallium.inria.fr/~remy/mpri/cours1.pdf

Reply on news.ycombinator.com