Why rust documentation has alike structs?
For an example, I can find two similar structs with different packages
Although their methods differ (e.g. std::ffi::CStr has into_c_stringwhile core::ffi::CStr),
the source code seemed to be the same.
Is there a reason to have two copies?
What would be the source of trust, and what should I use?
std::ffi::Cstr is just a re-export of core::ffi::Cstr with a few extra methods attached (note that the standard library gets to cheat and ignore the impl coherency rules to do this). In fact, every type in core is re-exported in std. Rust's standard library is split up into multiple parts to make things easier for embedded applications. The lowest level part is libcore. It does not assume any operating system or allocator- just that a small number of functions implemented elsewhere exist (a panic handler, plus a few functions related to 128-bit integer arithmetic and low-level data manipulation). The next level up is liballoc, which assumes libcore and a user-defined allocator exists. This is where things like Box and Vec are defined. Finally, on top of everything else, you have libstd: it re-exports liballoc and libcore, and provides a whole bunch of abstractions over OS APIs to do things like supporting file access and supplying a default allocator.
Then what's the rule of thumb to pick among multiple re-exports? I can't tell what's the baseline and what's the re-export, and documentation doesn't explain details for me to pick one.
You can - since std depends on core, std reexports whatever is defined in core. It can't be in another way, since core doesn't know about std at all.
Is there any other crates which have dependencies? I can indirectly assumes that std depends on core, but it's not written explicitly so it would be better if there's a easier way to get crate dependencies.
I don't get what you mean by "indirectly", but it doesn't matter much, either. Whatever the standard library exports, you can depend on it. You don't need to care whether it comes from core or it's defined in std itself. You don't need to know this "dependency".
(It's not like you can use dependencies automatically; unless explicitly reëxported, you can't use items from a transitive dependency.)
I meant that it's not explicitly mentioned whether core re-exports std or std re-exports core.
For me, I'd like to use the best crates but current documentation doesn't seem like to cover the guideline.
core couldn't possibly re-export std. Core is the smaller part of the library that assumes no OS. The additions in std need an OS. So the direction of the dependence is clear: std depends on core and not vice versa.
A good trick with rustdoc documentation to figure out which crate originally defined a re-exported item is to click the “source” button, and then look what crate the implementation it displays comes from, e.g. by inspecting the URL it takes you to.
If you do this on the CStr in std::ffi - Rust page, the “source” link takes you to somewhere in doc.rust-lang.org/stable/src/core/ffi/c_str.rs.html, i.e. in the core crate.
Unless you work in a no_std environment, I would always use std. It's what I see in most examples.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.