Why is the str datatype in rust declared in three different spaces?

[solvecodes]

why is the str datatype declared in three different spaces ?

core - alloc - std

why what is the point ?

[zirconium-n]

The ones from alloc and std are just reexports of core for convenience.

[solvecodes]

so str is originally from core ?

[ZiCog]

That is what reexports tells us.

[quinedot]

It's a primitive of the language, more like.

Rust Playground

[solvecodes]

how do i know if something is re-exported ?

[CAD97]

Copying over my answer from the duplicate on irlo in case it's useful:

@CAD97

If we want to get technical, str is "declared" in the compiler, because it's a primitive type.

The standard library is split between core, alloc, and std to coarsely represent different runtime support levels that targets can have. core is essentially target agnostic functionality^[1]

, alloc adds the concept of global dynamic heap allocation, and std adds functionality that interacts with the host OS environment.

So that most users of std don't have to think about this split, std reexports everything from core (think pub use) and uses #[doc(inline)] to present the documentation as-if it were defined inline instead of in a separate crate. There are also some rustc-specific exceptions to coherence checks that allow the three crates to pretend they're one for the purpose of conference (being allowed to write impls for locally defined types that you can't write for upstream types).

You can confirm that they're the same type because you can assign from a variable of type &core::primitive::str to one of type &std::primitive::str, and similarly for the other core/alloc names reexported from std.

This is generally referred to as the "std facade^[2]," and there's a long-running initiative to eventually reach "std reunification" where std is defined more like a library crate with feature flags than the current setup.

Other ecosystem crates on crates-io sometimes use a similar layered facade approach to split the implementation over multiple crates^[3]; notable examples include futures and bevy . More common than the many-crate approach is a two-crate split with a "core" and "full" API such as used by rand and rand_core (and I suppose getrandom could be included in this family).

@solvecodes

how do i know if something is re-exported ?

Usually, reexports are documented as such, like in the prelude modules where they show up under a "Re-exports" header and are displayed as a pub use. For #[doc(inline)]d items, there's no (immediate^[4]) indication in the docs whether an item is reexported or actually defined inline.

For the std facade specifically, it's by convention that items are reexported at the same path. If some item is available at both core::path::to::item and std::path::to::item, it's the same item, barring some niche historical edge cases^[5].

---

1. Caveat: some things like core::arch and core::atomic are only conditionally available based on architecture support. ↩︎

2. noun: facade; an outward appearance that is maintained to conceal a less pleasant or creditable reality. ↩︎

3. This can have benefits to compile time (if the crate dependency graph is wide, it enables further parallelism) and for crates that only need a subset of functionality to only depend on that subset, even if the entire package is included into the build tree (which allows better build pipelining by not waiting on building functionality a library doesn't need as well as core types being versioned more stably than the veneer) ↩︎

4. If you click the source link, it takes you to the actual item definition, so you can know by looking at the path of the defining file, e.g. /src/core/... or /src/std/.... And if the source link isn't available but is for other items (e.g. on docs-rs), that's usually indication that it's a cross-crate reexport. ↩︎

5. The panic! macro had subtly different behavior between core::panic! and std::panic! before the 2021 edition. This can mostly be attributed to macros not being useable early in Rust's lifetime and core not having access to format!, meaning the two macros had to be separately implemented with different functionality at the time. ↩︎