Totally.
When I see that a function is "in the standard library", it gives me a warm fuzzy feeling. Trying to analyze that, I think I'm making a bunch of assumptions:
-
Its design was seriously haggled over by experts.
-
It will be available for the foreseeable future.
-
I don't need to make any effort to install it.
-
Using it in my code won't cause portability hassles for other people building my code.
Availability (third and fourth points) is just not as big a deal now as it was in, say, 1990. Requiring someone to have a net connection to do an effortless build (with workarounds for unconnected use), is completely okay. "You already have a local copy!" doesn't justify too many warm fuzzy feelings anymore.
One of crates.io's goals is to keep published versions of crates available in perpetuity. (Or at least I thought so; I couldn't find this in the FAQ...) So that addresses the second point.
So we're left with the first point. I think the "standard library" is really (forgive me) a brand. It's an expectation of quality based on the reputation of the source. For example, In this view, the Boost C++ libraries are essentially a second brand that's managed to establish itself in parallel to (not really in competition with) the C++ standard.
It would be really cool if Rust could separate out the idea of "endorsed by The Good Folks Who Brought You Rust" from "appears under the std:: prefix". The libc crate is already in this state; you can't really use the FFI without it. And if, say, crossbeam is enough of a success that the people with responsibility for std:: feel it merits their endorsement, why shouldn't its author just hand over control to the project, rather than making everyone change their code?
If I could do crates.io searches narrowed by endorsement, with the heavy hitter projects (Rust, Servo, ...) treating endorsement as one of their responsibilities, I would totally do that all the time.