Skip to content
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

Closed
bstrie opened this issue Jul 2, 2013 · 12 comments · Fixed by #11956
Closed

Get rid of the std::util module #7556

bstrie opened this issue Jul 2, 2013 · 12 comments · Fixed by #11956
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone

Comments

@bstrie
Copy link
Contributor

bstrie commented Jul 2, 2013

Having a util namespace is an anti-pattern. Go through all the remaining types and functions in std::util and either move them to std::prelude or delete them outright.

15:28 < bstrie> though I'm sad that Noncopyable lives in a module named "util"
15:28 < bstrie> maybe we can find a better home for it
15:28 < strcat> prelude
15:28 < strcat> just shove it in prelude
15:28 < strcat> and swap/replace too
15:28 < bstrie> is that all that's left?
15:28 < strcat> no but the other stuff is pretty useless
15:28 < bstrie> haha
15:28 < strcat> id and ignore
15:28 < strcat> |x| x
15:29 < strcat> and .drop() being allowed explicitly could zap ignore
15:29 < strcat> or let _ = x; dropping immediately
15:29 < strcat> also Void, but we can put that in prelude
@brson
Copy link
Contributor

brson commented Jul 3, 2013

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, util is a grab bag of low-importance junk, while prelude is composed of the most important library definitions in Rust.

@thestinger
Copy link
Contributor

@brson: I think swap and replace are important enough to be in prelude, you can't write owned data structures without them (we did used to have <->). If we do replace ! and the implicit bottom with an uninhabited enum (#7538) it would make sense to have Void there too.

@bblum
Copy link
Contributor

bblum commented Aug 19, 2013

Here is the full list of items exported from util:

fn id
fn ignore
fn with
fn swap
fn replace
struct NonCopyable
fn NonCopyable::new
enum Void
fn Void::uninhabited
fn unreachable

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.

@bblum
Copy link
Contributor

bblum commented Aug 19, 2013

nominating backwards-compat

@thestinger
Copy link
Contributor

We'll be able to drop ignore once either let _ = expr destroys the result right away or drop takes self by-value.

The id function isn't really much more concise than just doing |x| x so we could remove that.

I don't think with should be in prelude, but the rest are okay.

@catamorphism
Copy link
Contributor

accepted for backwards-compatible

@edwardw
Copy link
Contributor

edwardw commented Jan 30, 2014

Now the leftover in std::util has been down to:

fn id
fn swap
fn replace
struct NonCopyable
fn NonCopyable::drop
enum Void
fn Void::uninhabited

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 prelude, except that id is to be removed?

@flaper87
Copy link
Contributor

I've a patch ready to remove NonCopyable as soon as #11768 lands.

@brson
Copy link
Contributor

brson commented Jan 30, 2014

Perhaps we could make std::util private while reexporting this stuff from the prelude. That would preserve the organizational advantages of having all this stuffed tucked into its own file while still not exposing the ugly util module.

@brson brson closed this as completed Jan 30, 2014
@brson brson reopened this Jan 30, 2014
@brson
Copy link
Contributor

brson commented Jan 30, 2014

Oops. Didn't mean to close.

@flaper87
Copy link
Contributor

I agree this looks like an easy task for a newcomer. I'll tag it as E-easy for now.

@edwardw
Copy link
Contributor

edwardw commented Jan 31, 2014

@flaper87, using NoPod marker I imagine? Then I shall try to take care of the rest.

@bors bors closed this as completed in 38ed467 Feb 11, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 12, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants