Thanks everyone for all the suggestions! I’ve tried to respond to some big ones below:

mikedilger: mikedilger: I’m still using std::old_io::process::InheritFd to daemonize, and std::old_io::Command to set stdout(), stderr() on the child, which then requires using std:old_path::Path.

Good point! I think we should be at least able to expose some platform-specific constructors if necessary, they shouldn’t be too hard to at least get unstable!

meqif: meqif: The only reason I’m still using std::old_io::net::udp::UdpSocket in my µTP implementation is because of set_timeout.

The only holdout for timeouts right now is stabilizing a Duration type, once we’ve got that we’ve got a pretty concrete plan of how to add back timeouts to UDP/TCP sockets. For now though I might recommend mio for more flavorful needs!

BurntSushi: BurntSushi: collections - std::vec::Drain

I would recommend replace + into_iter for now as the conventions around this method may not be quite in place for 1.0 to be stable.

BurntSushi: BurntSushi: core - std::num::cast, std::num::Int::{zero, one}, std::num::SignedInt::abs

We hope to do a large num stabilization PR before the end of the week. It may not hit all the points you’ve listed here, but it should definitely knock out a big chunk.

BurntSushi: BurntSushi: core - std::iter::Cloned

core - std::iter::AdditiveIterator

Both of these are pretty trivial to implement with other adaptors, but I think that Cloned may become stable. I’m less sure about AdditiveIterator becoming stable though (it’s been awhile since we looked at it.

BurntSushi: BurntSushi: core - std::str::Searcher, std::str::Pattern and std::str::SearchStep

I think we’re still working through whether we want this precise API to be stable for 1.0. Usage will be stable but custom implementations may not be. I’ll have to check up with Kimundi.

BurntSushi: BurntSushi: core - std::str::CharRange (used with char_range_at and char_range_at_reverse. I can get by with char_indices, but it’s slower). Similarly, std::str::StrExt::char_at.

I’ve found char_at + len_utf8 to be a good replacement for CharRange , but I haven’t personally taken much time to benchmark it yet. I do think we will likely end up stabilizing char_at .

BurntSushi: BurntSushi: core - std::ptr::PtrExt::as_ref and std::ptr::PtrExt::as_mut

I’d recommend .is_null

BurntSushi: BurntSushi: core - std::iter::range_step

Now it’s stable! https://github.com/rust-lang/rust/pull/23347

BurntSushi: BurntSushi: exit_status - std::env::set_exit_status essential for any CLI app.

We definitely want a method to set the exit status stable for 1.0, we’re still thinking about the precise method we’d like to do this though.

BurntSushi: BurntSushi: file_path - std::fs::File::path

I would recommend storing the path elsewhere for now, we’re likely to remove this.

BurntSushi: BurntSushi: fs_time - std::fs::Metadata::modified

Unfortunately this probably won’t be stable due to the lack of an abstraction for a moment in time. We’re considering exposing the raw representations in a stable fashion though so this could be calculated for comparisons at least.

BurntSushi: BurntSushi: io - io::Seek, io::SeekFrom, io::Write::flush io - io::Error and io::ErrorKind

Coming soon!

BurntSushi: BurntSushi: std_misc - The entry API. It’s very useful.

I believe @Gankra would know more on this, but I think the intention was for it to be stable for 1.0.

BurntSushi: BurntSushi: std_misc - std::path::AsPath

We’re hoping that generic conversion traits will obsolete this trait.

BurntSushi: BurntSushi: test - I think test::Bencher is the culprit here.

It’s likely that benchmarking will not be stable for 1.0. The good news is you only need it for tests though!

BurntSushi: BurntSushi: unicode - std::char::CharExt::encode_utf8 unicode - std::char::CharExt::width

We could plausibly stabilize encode_utf8 , but width will likely remain unstable for now.

gkoz: gkoz: The Str trait as in <S: Str, I: IntoIterator<Item = S>>

Vec::from_raw_buf

We’re hoping the generic conversion traits will obsolete Str , and I’m not sure that Vec::from_raw_buf will be stabilized. The implicit copy performed here isn’t really idiomatic with the rest of Vec 's API. I would recommend using slice::from_raw_parts and going from there.

csherratt: csherratt: std::os::num_cpus() Seems to have been deprecated this week (with std::os). Not sure sure if this api was meant to be moved into a different module or not.

We will likely not stabilize this function as there are a number of questions around its semantics. The current implementation, however, has been published on crates.io