lint idea: public Futures should be Send #5379
Labels
A-lint
Area: New lints
L-style
Lint: Belongs in the style lint group
T-async-await
Type: Issues related to async/await
Comments
flip1995
added
L-style
bors
added a commit
that referenced
this issue
Apr 17, 2020
add lint futures_not_send changelog: add lint futures_not_send fixes #5379 ~Remark: one thing that can (should?) still be improved is to directly include the error message from the `Send` check so that the programmer stays in the flow. Currently, getting the actual error message requires a restructuring of the code to make the `Send` constraint explicit.~ It now shows all unmet constraints for allowing the Future to be Send.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
One possible result of this discussion on Rust internals could be a lint that helps library maintainers in the large and the small (i.e. also between modules of the same crate) produce useful Future implementations when multithreaded executors are a possible runtime target. The lint would be disabled when targeting embedded systems where Futures are multiplexed onto the current thread only.
Informally specified, the rule would be that for any public function or method that returns an implementation of
Futurethe return type must also beSend.Is this feasible? Is this desirable?
The text was updated successfully, but these errors were encountered: