If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Saoirse Shipwreckt withoutboats Berlin In civilizations without boats, dreams dry up, espionage takes the place of adventure, and police take the place of pirates.

rust-lang/rustup 4209

The Rust toolchain installer

rust-lang/futures-rs 3996

Zero-cost asynchronous programming in Rust

smol-rs/smol 2116

A small and fast async runtime for Rust

rust-lang-deprecated/failure 1460

Error management

rust-lang/chalk 1168

An implementation and definition of the Rust trait system using a PROLOG-like logic solver

ringbahn/ringbahn 531

safe bindings to io-uring

ringbahn/iou 277

Rust interface to io_uring

rustasync/team 227

A point of coordination for all things Rust and Async

cargonauts-rs/cargonauts 175

A Rust web framework

issue commentvorner/arc-swap

const construct for ArcSwapOption

Yea, there's no way to make empty work since you can't call Default::default in a const context. Thanks for your quick attention to this :)


comment created time in 3 days

issue openedvorner/arc-swap

const construct for ArcSwapOption

It would be really nice if there were a const construct for ArcSwapOption.

created time in 4 days

pull request commentrust-lang/rust

Stabilize core::task::if_ready!

Yea, speaking as someone who maintains a big pile of downstream user code, I would find these libraries deprecating their ready macro to be annoying, not a disaster, but definitely annoying. I think it's important to keep in mind that async/await has been stable for almost 2 years now during which async Rust has had explosive growth. It's not the same phase anymore as 2018/2019.

I think the misinterpretation @hawkw describes is an important downside of if_ready, but I have a more abstract concern along the same lines: I don't think there's any succinct name for this macro that will make its operation immediately clear. Using a slightly opaque name like "ready" is helpful in this case because it makes it more obviously a "term of art" macro that users realize they need to look up to understand. With a name that tries to be self-explanatory, but could have misinterpretations, users are more likely to persist in their misunderstanding because they think they intuitively understand what the macro does without looking it up, but they are maybe wrong.


comment created time in 2 months

pull request commentrust-lang/rust

Stabilize core::task::if_ready!

I want to register why I think this choice is a mistake. I don't think its a disaster or anything and I don't have time to engage much, but I think it would be better to not rename this. I think the cost of renaming has been sharply underestimated in this process.

This isn't a new API. A macro with this functionality is provided by all of these crates: futures/futures_core, tokio, async_std, smol, and. futures_lite. It's basically impossible to write a crate in the async ecosystem today without depending on at least one of these. In all of these crates, this macro is called ready!.

Setting aside the question of whether this strong consensus is evidence that ready! is a good name or just normalcy bias (though I note that the maintainers of most of these crates :+1:'d my earlier comment in support of ready!), renaming this macro when stabilizing it in std increases substantially the churn costs. All of those libraries I cited have a pretty strong stability commitment, which means they will all continue to provide a macro with this functionality under the name ready!. ready! isn't going anywhere therefore; users will have to learn that the ready! macro from all of these libraries has the same functionality as if_ready! from std, and the stated clarity benefits of if_ready over ready (which I personally think are minimal to non-existent) will be reduced by the fact that users working in this area will have to read and understand code containing both forms.

I would encourage the teams to be a bit more quietist and only change the naming of ecosystem-consensus APIs with a really strong motivation. I don't think the motivation here is strong enough.


comment created time in 2 months