Library Teams Ambitions for 2022

# Library Teams Ambitions for 2022 * [Previous Discussion Notes](https://hackmd.io/je6I93XgQZGWFeXZdtZhfg?view#%E2%80%98Roadmap%E2%80%99---2022-themegoalfocus) ## Individual Goals _From [zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/2022.20roadmap)_ > Jane: I want to work on the roadmap some more today and am interested in reframing how approach developing the doc to be more similar to how the compiler team set up their 2022 ambitions document. Instead of coming at this from a "what should our theme be" I think it might be helpful to figure out what our collective current direction is, and identify the theme of our existing motivations. Along those lines I think it might be a useful exercise for each of us to answer the following questions: **Template** ### Name #### What work are you interested in doing in the coming year? #### What work are you interested in mentoring? #### What work do you think is important / needs doing? --- ### Jane (yaahc) #### What work are you interested in doing in the coming year? * Growing the library teams * Improving crate discoverability / official libs team 3rd party crate recommendations * Minimalist standard library, improving std's ability to evolve over time and reducing ossification of suboptimal APIs * Error handling project group * Error in core * Generic member access * provide_any * Error in panic * Document rust model of error handling * Specialization for `unwrap`, `expect`, `Termination` to report error via `&dyn Error` * Specialization to allow `Box<dyn Error>` to impl Error * What else do people think needs fixing with error handling? * Allocators * Storage API looks very cool * Fallible allocation * Non breaking methods (aka [Itertools::intersperse issue](https://github.com/rust-lang/rust/issues/88967)) #### What work are you interested in mentoring? * Everything within the error handling work above * New contributors, general mentorship for anyone interested in getting involved in the library teams #### What work do you think is important / needs doing? * The above * Portability Lint * Target tier policy - improving awareness and adherence across the project * Should the triage team know not to ping libs team members to review PRs for tier 3 targets and instead ping the Designated Developers? [example](https://github.com/rust-lang/rust/pull/88178). * Note on the example: netbsd doesn't appear to have any designated developers, does this mean it should be removed as a tier 3 target? * libs team blockers / needed features * extern existential types * module generics --- ### Amanieu #### What work are you interested in doing in the coming year? * Architecture-specific intrinsics in `std::arch`. * Finish and stabilize the remaining intrinsics for AVX-512 and ARM NEON. * Support architecture-specific types like `f80`, `f128`, `f16`, `bf16`. * These types would have be explicit imported via `std::arch`. * Needs some compiler support. * Opaque types which cannot be stored in memory. They have an unknown size and can only be used as local variables or as function arguments/return values. * Scalable vectors (AArch64 SVE, RISC-V V) * Wasm reference types * Improving the synchronization primitives in the standard library. * We want const constructors and don't want boxed types. #### What work are you interested in mentoring? All of the above, and also: * Allocators * Finalize the `Allocator` trait. * Look into using the `Storage` trait for Vec/Box. * Deprecate `GlobalAlloc` and replace it with `Allocator`. * Bindgen-based libc bindings * Currently the libc crate contains a huge amount of manually generated bindings. * A better approach would be to automatically generate Rust bindings using bindgen from a set of C header files. * We could take inspiration from how Zig does libc bindings. #### What work do you think is important / needs doing? * `Range` is an API wart that we don't know how to fix in a backward-compatible way. We want `Range` to be a `Copy` type which implements `IntoIterator` instead of an `Iterator`. * A better mechanism than lang items or fixed symbol names when an "inner" crate (e.g. core) needs to call functionality in an "outer" crate (e.g. std). * This applies to the global allocator, panic handler, global logger, etc. --- ### Josh Triplett #### What work are you interested in doing in the coming year? - Growing the library teams. - OsString/OsStr: exposing bytes on all platforms. - Stabilizing more features that have been in flight for a long time. #### What work are you interested in mentoring? - All of the above/below. #### What work do you think is important / needs doing? - Adding a more generic `Atomic<T>` type, for structures that fit in a machine word and could be handled atomically. - - Merging core/alloc/std. - Making build-std possible, and simpler. - Making std use fewer unstable library features. - Adding async traits and functions - Improving the maintainability of libc - Alternative implementation policy - Better support for Rust in the Linux kernel, using more of the Rust standard library. --- ### The 8472 #### What work are you interested in doing in the coming year? fd/Handle-based APIs for directories. This can build on the work done for the remove_dir_all CVE fixes. #### What work are you interested in mentoring? #### What work do you think is important / needs doing? --- ### simulacrum #### What work are you interested in doing in the coming year? * fmt::Arguments rework (performance/code size) #### What work are you interested in mentoring? * Open to suggestions. #### What work do you think is important / needs doing? * Providing * std::env MT-safe APIs (finalizing alternatives, etc.) --- ### Mara #### What work are you interested in doing in the coming year? - API: - Scoped threads. [tracking issue](https://github.com/rust-lang/rust/issues/93203) - Inheriting thread locals (or something in that direction) - Const `{Mutex, Condvar, RwLock}::new`. [tracking issue](https://github.com/rust-lang/rust/issues/93740) (see below) - Improve and then stabilize the new `Try` trait. - Support for unsafe code (e.g. methods on `MaybeUninit`, `Pin` etc.) - Also: documentation. - Get rid of lock poisoning. - A clearer definition of what the standard library is and isn't. - This could involve a clearer split between core and alloc/std. - Making the standard library 'less special' - E.g. we shouldn't make `String` more special than `some_other_crate::BetterString`. But we do, through e.g. `"a".repeat(2)` resulting in a `String`. - We probably can't change much about the existing APIs, but we can make guidelines for the future. - An alternative for the 'portability lint' based on where clauses. - Implementation: - Improving the synchronization primitives in the standard library. [tracking issue](https://github.com/rust-lang/rust/issues/93740) - Improving `fmt::Arguments` and `format_args!()` - Reducing the amount of unstable features we use in core/alloc/std. - Improve/refactor/clean up `std::sys`. - If RFC 2492 gets merged and implemented: Use that to simplify maintenance. - Organisational: - Detailed guidelines for reviewers and contributors. #### What work are you interested in supporting? - API: - Make it easier to work with OsStr[ing], Path[Buf], etc. - Implementation: - Make it possible to use std without libc (on Unix). - Organisational: - Help kick off some kind of 'library ecosystem' team to handle api guidelines, official crates like `log`, guiding users in the rust crate ecosystem, etc. #### What work do you think is important / needs doing? --- ## Suggested Theme/Focus/Goal/Direction - Making the standard library less special - Possibly via allowing custom literals? - Growing the standard library - Async runtime and standard traits? - Have a bunch of things that are currently being explored in crates.io crates, but will have converged to a single implementation by then. - fd-based/Handle-based APIs for directories (e.g. openat), and similar APIs with an emphasis on common infrastructure the ecosystem can build upon - Finishing the Allocator API on collections. - Lokathor: One thing i'd like to see is a source of randomness added in. I want to be clear here, I do not mean a rand like API with generators and ranges and such, I basically mean "finish moving the getrandom crate into std" - Improving on minimalist std mindset - Official 3rd party crate recommendations - brought up as part of discussion deprecating std's mpsc - came up again around std random API thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/seedable.20RNGs.20and.20risks.3F.3F.3F.3F.3F.3F.3F.3F.3F/near/272461258 - Improving discoverability of ecosystem crates - Improve process for moving code from popular crates into `std` (aka Itertools::intersperse issue) - Growing the team - More review bandwidth - More implementation bandwidth for libs-team wishlist items/blockers - Possibly largest impact on libs could be ‘existential types with external definitions’ (rfc 2492), to replace the global allocator, logger, etc. - Cleaner factorization of std libraries - No split between core/alloc/std - Build-std by default? - API evolution - How can we improve Range without breaking backwards compatibility? - Can we get rid of mutex poisoning (probably not). --- ## Notes on above suggestions Jane: the "making std less special" item could be recategorized as a subset of "finishing work in progress" or a general push to stabilize features, though this would not be a substantial change in direction from our recent status quo. Jane: the "growing std" and "improving on minimalist std mindset" goals could be recombined into a single "controlled growth" goal, where we try to improve the experience of experimenting in external crates but also improve the relationship between std and external crates and keep an eye on code that would benefit from moving into `std`. Jane: I know I mentioned not wanting the split between core/alloc/std in 5 years but compared to the other items I think that's more of a nice to have than a legitimately valuable core focus. Jane: Growing the team could also be joined into the "controlled growth" theme, where building a closer relationship with 3rd party crate maintainers helps us build a smoother on ramp for those maintainers into the library teams. Amanieu: It's unclear what concrete benefits we would get from merging core/alloc/std. What use cases does it enable or make more ergonomic? Jane: The main benefit I can think of is removing a substantial number of lang items which miiight help with the "make std less special" theme, but if that's the case then it should come up in the process of working on making std less special, at which point it will be clearly justified, so I don't think we should continue to track it independently. Amanieu: Build-std by default is great, but it's almost entirely on the Cargo side. There isn't much to do on the libs end (except perhaps dealing with feature flags).