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

Bounds for RwLock<T>: Send are unnecessarily restrictive #42934

Closed
RalfJung opened this issue Jun 27, 2017 · 1 comment
Closed

Bounds for RwLock<T>: Send are unnecessarily restrictive #42934

RalfJung opened this issue Jun 27, 2017 · 1 comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

Currently, RwLock<T>: Send requires T: Send and T: Sync. It would be sufficient to requires T: Send. (Transmitting an RwLock can't move an &T across thread boundaries.)

Is there interest in relaxing these kinds of bounds? Or, maybe, at least document the fact that the bounds could be more relaxed in the source?

@steveklabnik steveklabnik added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 27, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 28, 2017
@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 18, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 18, 2017

This bound was relaxed in #45267.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants