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

Remove rename of core to std in nostd builds #608

Closed
wants to merge 1 commit into from
Closed

Remove rename of core to std in nostd builds #608

wants to merge 1 commit into from

Conversation

AngelicosPhosphoros
Copy link
Contributor

Motivation:

Motivation:
* It is confusing
* It makes work on my other PR (#605) harder
* It makes harder to split nostd and std parts of crate
@Thomasdezeeuw
Copy link
Collaborator

I'm not going to accept this. We've had this convention for a long time and it works quite nicely once your past the initial surprise that std could also mean core. Furthermore we don't really want you use anything outside of core because that means that we'll break support for Rust targets without an OS.

@AngelicosPhosphoros
Copy link
Contributor Author

Furthermore we don't really want you use anything outside of core because that means that we'll break support for Rust targets without an OS.

You yourself told me in #605 to use std primitive (std::sync::Once and std::sync::OnceLock). They available only in std, not in core.

Also, in my opinion, not accepting std code is easier when it is clearly visible what comes from core, and what comes from std.

@Thomasdezeeuw
Copy link
Collaborator

You yourself told me in #605 to use std primitive (std::sync::Once and std::sync::OnceLock). They available only in std, not in core.

However I also stated (#605 (comment)):

However, I don't know the reason why the current approach was taken over using Once. It could be that the lack of support for targets without an OS was a deal breaker, I'm not sure.

So I think we should use it, but if it's not support on all targets the crate supports we can't (or we need some work around as we have for AtomicUsize).

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

Successfully merging this pull request may close these issues.

None yet

2 participants