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.

Sign up for GitHub

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

Jump to bottom

Rename core::comm::oneshot #5301

Closed
brson opened this issue Mar 9, 2013 · 3 comments
Closed

Rename core::comm::oneshot #5301

brson opened this issue Mar 9, 2013 · 3 comments
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Milestone
1.0

Comments

@brson
Copy link
Contributor

brson commented Mar 9, 2013

As in #5300, this function and associated types will be very heavily used once they work reliably. I don't like the name all that much.
@Aatch Aatch mentioned this issue Jun 7, 2013
Closed
@bblum
Copy link
Contributor

bblum commented Jun 19, 2013

perhaps once_pipe for the function name, and OnceChan and OncePort for the type name, to correspond to the OnceClosure traits we're going to have to have.

alternatively, Chan1 and Port1, for increased conciseness but less approachability.

@bblum
Copy link
Contributor

bblum commented Aug 5, 2013

yes hello, this is triage speaking, nothing to contribute since my last comment

@alexcrichton
Copy link
Member

Oneshots have been removed.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2020
@bors
Auto merge of rust-lang#5301 - JarredAllen:option_if_let_else, r=flip…
ac85692 
…1995

Suggest `Option::map_or`(_else) for `if let Some { y } else { x }`

Fixes rust-lang#5203

There are two issues with this code that I have noticed:

- Use of `Option::map_or` causes it to always evaluate the code in the else block. If that block is computationally expensive or if it updates some state (such as getting the next value from an iterator), then this change would cause the code to behave differently. In either of those circumstances, it should suggest Option::map_or_else, which takes both cases as a closure and runs one. However, I don't know how to check if the expression would change some state, so I left the lint's applicability as MaybeIncorrect.

- There are lints which can trigger on specific sub-cases of this lint (`if_let_some_result`, `question_mark`, and `while_let_loop`) and suggest different changes (usually better ones because they're more specific). Is this acceptable for clippy to give multiple suggestions, or should I have the code check if those other lints trigger and then not trigger this lint if they do?

changelog: Add lint [`option_if_let_else`]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-concurrency Area: Concurrency A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
3 participants
@alexcrichton @brson @bblum