3 ms·
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
by 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 agoIf 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 agoThe 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.