5 ms·

A simple "--make-borrow-violations-into-warnings" flag (that for the sake of the panicky would work only on debug builds) would let you get on with your work, a

A simple "--make-borrow-violations-into-warnings" flag (that for the sake of the panicky would work only on debug builds) would let you get on with your work, and come back before pushing to a shared repository to settle up. Probably need to release it as a patch so as not to need approval of the purity gatekeepers. People using it get an immediate boost in productivity as it enables exploration with no ultimate reduction in safety.

returningfory2 3y ago
Do you think there should also be a “--make-type-violations-into-warnings’ flag?
- estebank 3y ago
  I think there would be value of such an option, as long as it would be completely forbidden to publish to crates.io with code that only works with those flags. It could work by replacing any function with type errors (including those caused by type definitions) to panic on use, but otherwise still generate a binary. For type errors it is less useful than for lifetime errors because usually the problems of the former are very local while for the later it they are not.
cornholio 3y ago
Sounds like a great way to paint yourself into a corner, and explore solutions that are impossible to be made viable in the general case, even if they happen to work for certain inputs during debug.
- estebank 3y ago
  I would like that mode exclusively for the test suite to use. That way you start writing your tests, and if there's a borrowck error You delay that until the test runs. If it runs, and then it fails when accessing data, you can give more information to the programmer about the failing case. If it runs successfully, you just fail that one test with the borrowck error. I would love it if we could have something akin to prop test for borrowck so that even the test isn't needed.
- angiosperm 3y ago
  You would not ever be obliged to use the flag, so its presence would not affect you. It doesn't matter whether it "works for certain inputs", or for any inputs. The point is to be able to direct attention to more immediately important algorithmic matters now, and then address borrow checker pedentism once actually difficult questions are resolved. The point is not to be able to ship code with borrow violations. It is hard for me to understand what is so difficult about this distinction.
  - estebank 3y ago
    If that's the workflow you want during development, you can always replace references with a RwLock. That of course is not made very fun by neither the language (you need to touch too many places in your code to switch back and forth) nor the tooling (we need more advanced refactoring tools, if the language won't change, I'd love it if we had an "add a lifetime to this type everywhere" action in my editor).
  - cornholio 3y ago
    The distinction is quite clear, the reason to ever use such a flag - less so. Toolchain features are very much a popularity contest, if there is no real reason to add a feature (and, in fact substantial reason not to), it shouldn't be implemented. The idea to use it during rapid prototyping is especially problematic, since that's the point where pernicious data access patterns will infect the entire design. Once the application "works, save from some double free bugs in weird testcases we don't expect in production, and which require a one month refactoring", the temptation to ship the flag into production will become overwhelming.
voxl 3y ago
You should just not use Rust. A language should hold strong to its philosophical principles. These kind of changes are fundamentally design by committee.
- dmurray 3y ago
  I agree in principle - what's the point in deciding to use Rust but turning off the borrow checker? But on the other hand - Rust already has unsafe mode, which is exactly for allowing you to avoid some safety checks when you've decided you are smarter than the compiler - this really is an example where the compiler isn't smart enough, as evidenced by the fact there are plans to make it work So another "unsafe" type of marker that watered down the borrow checker would not be totally inconsistent with the language philosophy. It should work at the block or the file level, though - surely you wouldn't want to turn that off for all your code.
  - apendleton 3y ago
    The whole point of the current `unsafe` mechanism is that you have to explicitly opt one specific chunk of the code out of stricter checking, and it's obvious which chunk of code it is that needs that behavior (the bit inside the block) and which isn't (everything else) -- that bit can be subjected to extra scrutiny upon review, and there's a community-wide shared understanding of what invariants that chunk needs to uphold for the program as a whole to be sound. I'd argue that the alternative mechanism you propose (a compiler flag), which just opts the whole program out of strict checking, _is_ fundamentally philosophically different. Having the opt-in/opt-out mechanism be block-level is a language-design/philosophical decision.
    - dmurray 3y ago
      Right, I didn't propose a compiler-level flag (though the original suggester did), I specifically said it needs to work at the block or file level.
duped 3y ago
A program with borrow checking violations is incorrect the vast majority of the time. Not something to be "settled up" but something that is wrong.
- angiosperm 3y ago
  Most of the code you write is similarly incorrect at first. Then you fix it, and then it's right. Unless you ship the buggy code, the bugs harm nobody. Likewise, borrow failures. It is hard to understand what is so difficult about this concept.

returningfory2 3y ago

Do you think there should also be a “--make-type-violations-into-warnings’ flag?

estebank 3y ago
I think there would be value of such an option, as long as it would be completely forbidden to publish to crates.io with code that only works with those flags. It could work by replacing any function with type errors (including those caused by type definitions) to panic on use, but otherwise still generate a binary. For type errors it is less useful than for lifetime errors because usually the problems of the former are very local while for the later it they are not.

cornholio 3y ago

Sounds like a great way to paint yourself into a corner, and explore solutions that are impossible to be made viable in the general case, even if they happen to work for certain inputs during debug.

estebank 3y ago
I would like that mode exclusively for the test suite to use. That way you start writing your tests, and if there's a borrowck error You delay that until the test runs. If it runs, and then it fails when accessing data, you can give more information to the programmer about the failing case. If it runs successfully, you just fail that one test with the borrowck error. I would love it if we could have something akin to prop test for borrowck so that even the test isn't needed.
angiosperm 3y ago
You would not ever be obliged to use the flag, so its presence would not affect you. It doesn't matter whether it "works for certain inputs", or for any inputs. The point is to be able to direct attention to more immediately important algorithmic matters now, and then address borrow checker pedentism once actually difficult questions are resolved. The point is not to be able to ship code with borrow violations. It is hard for me to understand what is so difficult about this distinction.
- estebank 3y ago
  If that's the workflow you want during development, you can always replace references with a RwLock. That of course is not made very fun by neither the language (you need to touch too many places in your code to switch back and forth) nor the tooling (we need more advanced refactoring tools, if the language won't change, I'd love it if we had an "add a lifetime to this type everywhere" action in my editor).
- cornholio 3y ago
  The distinction is quite clear, the reason to ever use such a flag - less so. Toolchain features are very much a popularity contest, if there is no real reason to add a feature (and, in fact substantial reason not to), it shouldn't be implemented. The idea to use it during rapid prototyping is especially problematic, since that's the point where pernicious data access patterns will infect the entire design. Once the application "works, save from some double free bugs in weird testcases we don't expect in production, and which require a one month refactoring", the temptation to ship the flag into production will become overwhelming.

voxl 3y ago

You should just not use Rust. A language should hold strong to its philosophical principles. These kind of changes are fundamentally design by committee.

dmurray 3y ago
I agree in principle - what's the point in deciding to use Rust but turning off the borrow checker? But on the other hand - Rust already has unsafe mode, which is exactly for allowing you to avoid some safety checks when you've decided you are smarter than the compiler - this really is an example where the compiler isn't smart enough, as evidenced by the fact there are plans to make it work So another "unsafe" type of marker that watered down the borrow checker would not be totally inconsistent with the language philosophy. It should work at the block or the file level, though - surely you wouldn't want to turn that off for all your code.
- apendleton 3y ago
  The whole point of the current `unsafe` mechanism is that you have to explicitly opt one specific chunk of the code out of stricter checking, and it's obvious which chunk of code it is that needs that behavior (the bit inside the block) and which isn't (everything else) -- that bit can be subjected to extra scrutiny upon review, and there's a community-wide shared understanding of what invariants that chunk needs to uphold for the program as a whole to be sound. I'd argue that the alternative mechanism you propose (a compiler flag), which just opts the whole program out of strict checking, _is_ fundamentally philosophically different. Having the opt-in/opt-out mechanism be block-level is a language-design/philosophical decision.
  - dmurray 3y ago
    Right, I didn't propose a compiler-level flag (though the original suggester did), I specifically said it needs to work at the block or file level.

duped 3y ago

A program with borrow checking violations is incorrect the vast majority of the time. Not something to be "settled up" but something that is wrong.

angiosperm 3y ago
Most of the code you write is similarly incorrect at first. Then you fix it, and then it's right. Unless you ship the buggy code, the bugs harm nobody. Likewise, borrow failures. It is hard to understand what is so difficult about this concept.