> I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature? In theory, possibly. In practice, there are

> I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature? In theory, possibly. In practice, there are a number of technical and social obstacles standing in the way of such a feature. The first big technical problem is that standard C is currently not very well-suited for borrow checker-style automated lifetime/ownership analysis. Much of the information the borrow checker needs just not present in the C type system, and while some information may be inferable from function bodies separate compilation and the dynamic nature of ownership make things really hard, if not impossible in the general case. Of course, one could require the addition of lifetime/ownership annotations, but that is a pretty substantial backwards compatibility break - there's a lot of existing C code out there, and they'd need to be annotated to be usable in a Rust-style borrow checker. That's an automatic deal-breaker for a lot of people. So what happens if you just try to work with what you have? Then you basically end up where existing static analysis tools are - they can catch some lifetime/ownership errors, but that's on a best-effort basis an can potentially be very resource-intensive. > why do we have to write "let" to define a variable? The most common explanation I've seen is that it makes parsing and/or type inference easier. In addition, let is also more than just a variable declaration - it can be used more generally for binding/destructuring/pattern matching (e.g., if let Some(Point(x, y)) = p { do_something(x, y) }. > why did they completely change the syntax if the goal is to be a C alternative!? Because those changes are (arguably) improvements?