4 ms·

Forget all this drama, I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature? And since it's just a co

Forget all this drama, I wonder if we can have a Borrow Checker, like the one Rust has, implemented on top of C as an optional feature? And since it's just a compile-time thing, it won't cause any incompatibility or breakage at runtime. I love the idea of having the memory safety features that the Rust compiler offers, but I find Rust unreadable, it hurts my eyes, why do we have to write "let" to define a variable? why did they completely change the syntax if the goal is to be a C alternative!?

aw1621107 2y ago
> 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?
- cantrelate 2y ago
  > 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. Yeah unfortunately.
- cantrelate 2y ago
  Looks like we will get that borrow checker after all :) "The affine type system makes it easier to relocate objects without breaking type safety. Pattern matching, which is safe and expressive, interfaces with the extension’s new choice types. Borrow checking,[borrow-checking] the most sophisticated part of the Safe C++, provides a new reference type that flags use-after-free and iterator invalidation defects at compile time." https://safecpp.org/P3390R0.html https://safecpp.org/P3390R0.html
whytevuhuni 2y ago
To me it seems like the goal was to be a C++ alternative, not C. I do half-agree though... I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes. I'd love to see that language.
- cantrelate 2y ago
  > To me it seems like the goal was to be a C++ alternative, not C. That's probably the reason. > I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes That's exactly the language I would like to upgrade to from C.

aw1621107 2y ago

> 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?

cantrelate 2y ago
> 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. Yeah unfortunately.
cantrelate 2y ago
Looks like we will get that borrow checker after all :) "The affine type system makes it easier to relocate objects without breaking type safety. Pattern matching, which is safe and expressive, interfaces with the extension’s new choice types. Borrow checking,[borrow-checking] the most sophisticated part of the Safe C++, provides a new reference type that flags use-after-free and iterator invalidation defects at compile time." https://safecpp.org/P3390R0.html https://safecpp.org/P3390R0.html

whytevuhuni 2y ago

To me it seems like the goal was to be a C++ alternative, not C. I do half-agree though... I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes. I'd love to see that language.

cantrelate 2y ago
> To me it seems like the goal was to be a C++ alternative, not C. That's probably the reason. > I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes That's exactly the language I would like to upgrade to from C.