Open xd009642 opened 7 years ago
Subconditions are ordered in c++, too and often this is required. E.g. foo.len() > 3 && foo[2]
is guaranteed panic free.
For bit operations instead of short circuiting operations this makes sense though. I think we already have an issue for eval order unclearness
https://github.com/rust-lang-nursery/rust-clippy/issues/1193
Fair enough, I guess this is the issue with spending the day job doing MISRA C you forget what is paranoia and what is language spec :smile: I'm happy closing this issue if you think there's nothing that needs doing
I guess this is the issue with spending the day job doing MISRA C you forget what is paranoia and what is language spec
It never hurts to be paranoid. Please bring in your experience with MISRA-C by scrutinizing Rust code! We can really use an experienced eye from mission critical software development.
We could have a restriction lint that disallows side-effects in boolean chains. I think this could often result in a gain in readability. What do you think?
True true, when I have time I'll look over my copy of the MISRA standard and open an issue with warning lints related to MISRA violations/warnings. It's a good first step in getting the safety of rust onto things like automobiles etc :smile:
So disclaimer, I'm not sure if this is a necessary lint (anyone with input see my rust forum post https://users.rust-lang.org/t/evaluation-order-of-boolean-subconditions/13748). But I have the feeling that boolean subcondition execution order is probably not guaranteed like in C and C++. Therefore, if a user had side-effects in a subcondition program behaviour could change significantly due to something like a changed optimisation flag.
Below is some code which should be warned against if this lint is necessary. If this is an issue I wouldn't mind implementing the lint to help out :smile: