Recently, it has been proposed to make a breaking change in the async-io crate to use I/O safe abstractions rather than AsRawFd (smol-rs/async-io#136). This would be a very large breaking change, since async-io is also re-exported in smol. Therefore, a breaking change in async-io would lead to use releasing smol v2.0.0. This issue aims to discuss if this should be done, how this should be done, and the potential impacts of this being done.
Discussion Questions
1). Should this happen?
First off, we should ask if this should even happen in the first place. It would be best for ecosystem cohesion to avoid a breaking change, after all. It was suggested that we could just add another constructor to Async that takes an AsFd type. However, it's been three years since smol v1.0.0 was released, and there are other breaking changes that could be made (see below). So the question is: are these breaking changes worth the major version bump?
2). What should happen?
Proposed examples of breaking changes, feel free to add any that I missed:
async-fs
async-lock
- Add a default
std feature for no_std usage
async-io
- `futures-lite
3). Who would be impacted?
async-std re-exports some of our crates in their public API, so this would affect them. cc @joshtriplett and @yoshuawuyts: are you find with this?
Recently, it has been proposed to make a breaking change in the
async-iocrate to use I/O safe abstractions rather thanAsRawFd(smol-rs/async-io#136). This would be a very large breaking change, sinceasync-iois also re-exported insmol. Therefore, a breaking change inasync-iowould lead to use releasingsmolv2.0.0. This issue aims to discuss if this should be done, how this should be done, and the potential impacts of this being done.Discussion Questions
1). Should this happen?
First off, we should ask if this should even happen in the first place. It would be best for ecosystem cohesion to avoid a breaking change, after all. It was suggested that we could just add another constructor to
Asyncthat takes anAsFdtype. However, it's been three years sincesmolv1.0.0 was released, and there are other breaking changes that could be made (see below). So the question is: are these breaking changes worth the major version bump?2). What should happen?
Proposed examples of breaking changes, feel free to add any that I missed:
async-fsasync-lockstdfeature forno_stdusageasync-ioAsFdinstead ofAsRawFdin the public API (Support creating anAsyncwithAsFdrather thanAsRawFdasync-io#136)stdin the public API (Dropfuture::{ready,pending}at the next bigger release futures-lite#35)3). Who would be impacted?
async-stdre-exports some of our crates in their public API, so this would affect them. cc @joshtriplett and @yoshuawuyts: are you find with this?