What is the goal of this crate in terms of being used as part of a public API?

[elinorbgr]

On a project I'm working on we have some crate for which it would make a lot of sense to have OwnedFd as part of its public API, however we don't want to bump our MSRV to 1.63 just yet.

One of the options we are considering is to publicly depend on io-lifetimes and use its types and traits instead. However I'd like to be sure if this is the way this library is meant to be used? Looking at #38, it appears that the main focus of the project is to actually migrate the ecosystem to the std types and traits.

[sunfishcode]

Yes, this io-lifetimes crate is intended to be used in that way, and it has an MSRV of 1.48. The overall focus is to migrate the ecosystem to use the std types and traits, but the goal is to do so gradually, so I plan to continue to maintain this io-lifetimes crate specifically to help people who aren't ready to bump their MSRV yet migrate.

The main area where things get tricky is implementations of the I/O safety traits such as AsFd for third-party types. This comes up if you want to use eg. AsFd in a public API, and your users want to pass in eg. a socket2::Socket.

• If you use the current version, 0.7.3, you can enable Cargo features such as "socket2", and others, to enable implementations for types in the corresponding crates.
• There is also an io-lifetimes 1.0.0-rc1 pre-release, which switches to using the types and traits from std on Rust >= 1.63, and continues to use its own types and traits otherwise. But because of Rust's orphan rule, io-lifetimes can't provide implementations for the std traits for types defined in other crates. As discussed in Quest: Gradually migrate the Rust ecosystem to I/O safety #38, there is work underway to add implementations to various popular crates, however it'll take time.

You can ignore the 1.0.0-rc1 pre-release, and upcoming 1.0.0 release, and just use 0.7.x for now. However over time you might encounter incompatibilities if your users start using the std types and traits. So there are a few different possible approaches here, and it depends on your needs. I'm happy to answer any questions you might have.

[elinorbgr]

Okay, thanks a lot for those clarifications.

From what I gather it seems that what corresponds the most to my needs would actually be to use the 1.0 and use its OwnedFd type in my public API: I need to represent passing FDs over a unix socket, and OwnedFd is really the type that semantically represents that.

[sunfishcode]

That sounds right to me!

[elinorbgr]

Alright, thanks!