5 ms·

Removing the borrow checker would allow you to compile broken code (eg. use after free, data races). However given code that compiles on rustc - passes the borr

Removing the borrow checker would allow you to compile broken code (eg. use after free, data races). However given code that compiles on rustc - passes the borrow checker - you don't need to reverify the borrow checking to get correct code from mrustc.

banachtarski 9y ago
(note, not the OP) Yea but by the same token, the borrow checker prevents me from doing perfectly valid logic and is frustrating in its own right.
- angelsl 9y ago
  There are probably assumptions/invariants built into how rustc generates LLVM IR that you will have to guarantee are met if borrowck is disabled. Do you really want that?
- moomin 9y ago
  That's true of literally all compile time validation.
  - weberc2 9y ago
    But its more true of some than others.
  - banachtarski 9y ago
    No I'm not saying I have an issue with compile time validation. Far from it. My point is that the borrow checker is explicitly meant to protect against data races and such. There are situations where I write code I can prove does not violate any hazards but Rust's "validation" is overly-zealous.
    - steveklabnik 9y ago
      Which ones do you run into most often?
- keeperofdakeys 9y ago
  Yes, some valid code won't pass the borrow checker. But at the same time, far more invalid code doesn't pass it. Personally I see it as a tool to help me reduce possible runtime errors, and instead have them as compile time errors. This does mean that I often need to design my program around it, but that's try of basically every other language. The few times I do have an issue I'm usually writing FFI code to interact with C, and I try to minimise that code as much as possible.
  - tmzt 9y ago
    And of course in Rust, if you Try you might get an Ok Result, or you may just return in Err. It's often a good exercise to craft your program to the language you're targetting, to take advantage of it's strengths or embrace it's traditions.

banachtarski 9y ago

(note, not the OP) Yea but by the same token, the borrow checker prevents me from doing perfectly valid logic and is frustrating in its own right.

angelsl 9y ago
There are probably assumptions/invariants built into how rustc generates LLVM IR that you will have to guarantee are met if borrowck is disabled. Do you really want that?
moomin 9y ago
That's true of literally all compile time validation.
- weberc2 9y ago
  But its more true of some than others.
- banachtarski 9y ago
  No I'm not saying I have an issue with compile time validation. Far from it. My point is that the borrow checker is explicitly meant to protect against data races and such. There are situations where I write code I can prove does not violate any hazards but Rust's "validation" is overly-zealous.
  - steveklabnik 9y ago
    Which ones do you run into most often?
keeperofdakeys 9y ago
Yes, some valid code won't pass the borrow checker. But at the same time, far more invalid code doesn't pass it. Personally I see it as a tool to help me reduce possible runtime errors, and instead have them as compile time errors. This does mean that I often need to design my program around it, but that's try of basically every other language. The few times I do have an issue I'm usually writing FFI code to interact with C, and I try to minimise that code as much as possible.
- tmzt 9y ago
  And of course in Rust, if you Try you might get an Ok Result, or you may just return in Err. It's often a good exercise to craft your program to the language you're targetting, to take advantage of it's strengths or embrace it's traditions.