3 ms·

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

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.

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.