How hard would it be to suppress unused variable warnings for functions that invoke the unimplemented!() (aka todo!()) macro? Who should I talk to to suggest it and how do I reach them?
Posted Mar 25, 2020, 5:30 PM UTC · edited
Interestingly enough, if you don't need the varargs feature of todo!, you can use a function border so that the compiler doesn't warn about unused/unreachable:
fn todo<T>() -> T { todo!() }
The easiest is to just put it in an if true { todo!() }
[deleted]
I like the idea, but it's harder than it looks, because you could use unimplemented in just one branch of a function. The compiler would have to do some kind of flow-sensitive analysis in order to suppress the warnings on just that path.
I think it's a good idea, and I've wanted this. Just saying it's not as easy as suppressing the warning for all args.
Is there a case where a method isn't fully implemented but you do want the warning? It seems to me like if the method isn't done for whatever reason the programmer has more important things to think about.
Yes, I use this all the time. unimplemented!() means "if you reach this code path, then the request is understood but not implemented". It doesn't mean "this entire function is unimplemented".
If it did, we would just-reinvent the path-dependent version, like so:
fn my_partially_implemented_function() {
if ... {
... good stuff ...
} else {
// not finished here
(|| unimplemented!())();
}
}
Using `unimplemented!()` in one control flow path of a partially-implemented function is no different from having a partially-implemented function that expresses the same idea by calling a separate function, which itself is "unimplemented".
Hmmm, okay. I think I see what you're saying, and it would suggest the flow analysis approach. Someone over on internals suggested the policy "any variable that is in-scope on a unimplemented!() is assumed to be used", which seems pretty ideal to me, what do you think?
Not ideal, but let _ = (arg1, arg2, arg3,…); before the macro works.
Sure, as does prefixing the variables with underscores. It's not hard to do manually, it's just a ubiquitous situation during development, so automating it would be nice.
If you've got so many unimplemented functions, you should just be using underscores all the time. Why name variables if you're still designing interfaces?
Partially so I can keep track of my intentions, but also because little details can be forgotten, and if I forget to change an underscore because I forgot to use a parameter, the unused variables warning won't work.
Hey
You can create an issue on rust-lang/rust. But tbh i don't see this being implemented. (Sounds like too much for too little gain) but feel free to create the issue anyway :) Thanks
You should post your suggestions on http://internals.rust-lang.org
Done, thanks for the pointer.