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

Why are these types not in the standard library? #36

Closed
torkleyy opened this issue Jun 9, 2017 · 4 comments
Closed

Why are these types not in the standard library? #36

torkleyy opened this issue Jun 9, 2017 · 4 comments

Comments

@torkleyy
Copy link
Contributor

torkleyy commented Jun 9, 2017

I'm asking myself, if these are faster why aren't they in libstd? I think read something about platform limitations, but it's not really clear why the standard library has to use platform-specific types. I also saw other people wondering about this, might be worth adding it to the README.

@Amanieu
Copy link
Owner

Amanieu commented Jun 9, 2017

See rust-lang/rfcs#1632.

@torkleyy
Copy link
Contributor Author

torkleyy commented Jun 9, 2017

Great, thanks! I think I'll be using this crate only then. 👍

@torkleyy torkleyy closed this as completed Jun 9, 2017
@Techcable
Copy link

@alexcrichton mentioned getting this in the nursery. Is that a possibility?

@tbu-
Copy link

tbu- commented Sep 10, 2018

In rust-lang/rust#53127 (comment) it is mentioned that Rust might be more likely to accept parking_lot into the standard library (even rustc uses parking_lot).

It's probably needed to write another RFC to make that change though. I don't think I have the necessary expertise to write it. If someone were interested in this and had some time, it would be nice if they could write it. :)

One more possible concern that didn't get mentioned in the original RFC thread would be whether the code size of parking_lot is bigger than the one of the synchronization primitives in libstd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants