Closed AngelicosPhosphoros closed 7 months ago
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.
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
.
You yourself told me in #605 to use std primitive (
std::sync::Once
andstd::sync::OnceLock
). They available only instd
, not incore
.
However I also stated (https://github.com/rust-lang/log/pull/605#issuecomment-1861325083):
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
).
Motivation: