-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of the std::util
module
#7556
Comments
I'm not sure about putting things directly in the prelude. Currently it is only reexports. Defining things directly in the prelude isn't something we should do lightly. Furthermore, |
Here is the full list of items exported from util:
With the exception of wishing we had a more concise name for the noncopyable token, I would be fine with all of this being in prelude. |
nominating backwards-compat |
We'll be able to drop The I don't think |
accepted for backwards-compatible |
Now the leftover in
Seems to be the perfect candidate for a contributor wanna-be to try hand on. My question then is it okay to move all these to |
I've a patch ready to remove |
Perhaps we could make |
Oops. Didn't mean to close. |
I agree this looks like an easy task for a newcomer. I'll tag it as E-easy for now. |
@flaper87, using |
…ip1995 No effect inclusive range I noticed during last PR that range expression is `ExprKind::Struct` while inclusive range is `ExprKind::Call` which was why it was not handled. This PR adds check for this case. changelog: [`no_effect]` Report inclusive range in no_effect lint
Having a
util
namespace is an anti-pattern. Go through all the remaining types and functions instd::util
and either move them tostd::prelude
or delete them outright.The text was updated successfully, but these errors were encountered: