What do you mean "twice"? You have a function that takes some parameters. You want to verify that it makes all variants. The compiler can tell you if you syntactically make them, but not that all are actually reachable. So you generate a set of parameters to tickle each codepath and use a match on the type you're interested in. If a new variant shows up, your the compiler flags your test about the missing new variant in its match, so you add a new argument set to prove that it is reachable. The only thing missing is std::mem::discriminant_index_of(a) to manage the index matching automatically.
Also, the compiler is going to almost certainly be lost if the function delegates some variants to another function, so you're still left with "test the thing" approach once things get moderately complicated.
A few points:
i. Since this lint is opt-in, clippy needn't worry about performance, so it will recursively check functions. Optionally you could avoid this with a sufficient flag, e.g. #[sufficient(Ok(_), Err(false))] (this wont cover Err(true)) or #[sufficient(1..u32::MAX)] (wont cover 0_u32) above your branch.
ii. Addressing what you said yesterday (at least in my local time), what you said it exactly the issue I'm dealing with (that caused me to open this post): I have a program that interacts with multiple APIs, and needs to be able to convert the specified CPU arch into a string for the api. Currently the program only supports ~10% of CPUs (e.g. PowerPC is not yet supported), so if I am to add support for another CPU, I have to modify every single api arch handler (double that - one to string and one from) to support the new arch. Adding the from_str is easy b/c the compiler will fail if I miss a branch. but from? I have no qay of knowing if I have forgotten one of the APIs. Tests will not solve the issue - how can I ensure I have also modified the actual code (in addition to the test)? B/c now I will have three functions to rewrite for each API. And is you want to call this a "skill issue", then we should abolish Result and Option - you should've ensured that we can write a file to that location/the API is running correctly/the YAML file is written correctly.
I'll leave that up to the clippy developers to indicate whether that is feasible or not. I'm almost certain cross-crate isn't feasible.
I presume you mean to_str here, but it doesn't really matter. It sounds like you want something like strum here.
I don't think I'm calling it a "skill issue". Turing complete languages have inherent complexity to checks like this. If you have one return behind a if blackbox_predicate(), that variant might be essentially unreachable in practice. Given the severe preference for low false positive rates, I'm not sure how useful it is in practice for anything that isn't strum-able.
The idea is to set up safety nets that will help catch mistakes automatically. Yes, clippy would be nice, but given the complexities and a lack of timeline, I think you still want something like the test above in complicated cases until a lint does exist.
- Oh absolutely - cross-crate will require a #[sufficient] (and recursion is ignored, so thir flag will be required in an event where you have
MyType::SomeVarient(Box<MyType>)- nested Self). - Yeah (tho I called it parse for consistency with other crates). I just looked at the strum crate's readme, but I don't see support for multiple FromStr - but then again I fully understand that requiring multiple implementations for struct/enum S (depending on whether it is nested in struct/enum X or Y) is a very niche use-case. 3.i) I understand it is incredibly complicated, but looking at the rfc/issue/etc above, it seems this feature is wanted. 3.ii) Oh I got the impression that you were suggesting a test as a solution, not an intermediary substitute.