Rust Keyword Generics Progress Report: February 2023

Hi, post author here. A lot of the work we've been doing here has specifically been motivated by the unification of existing std Iterator, the async Stream trait, and the ability to use loops in const contexts (e.g. a const version of Iterator). We actually have a version of the async Stream trait on nightly Rust in the async_iter submodule. However, a major downside of it is that in its current form it is scheduled to become a carbon-copy of the existing std::iter crate, with the only difference being that most functions and closures will be prefixed with the async keyword. That's a lot of duplication which needs to be maintained, just because because we wanted an async version of one interface. And it's likely at some point the stdlib will want to provide its own version of async TcpStream, async File, etc. - and that would result in an enormous amount of duplicate APIs which would largely be identical to their non-async counterparts.

And the problems don't just stop with async either. Have you ever wondered why you can't just use the ? operator from a closure? Or have you seen the Rust for Linux project ask whether they could have non-panicking versions of certain APIs? We don't want the answer to those kinds of asks to be: "We'll add an identical version of the same API which differs on exactly one dimension". That would either set us on the path to an exponential blowup of API surface, or needing to make hard choices on which APIs we don't want to support in certain contexts. Instead we believe the best path to solving this is through the type system - like we're already doing with const - and that's why we started the work on the Keyword Generics Initiative.