# Libs(-API) cross-team wishlist

- crate nmespaced features: `#![feature(std::feature)]`
- literals that can be other custom types too. E.g. `1.0` being a FastF32 if the context makes that so.

---
Stuff below was already discussed in a lang meeting. Notes of that meeting are here: https://hackmd.io/iIUKTpmPRlG-fBkjDl-nYQ

- Something to allow PartialEq between options of different types, without breaking `Some(1) == None` etc.
- scottmcm: Maybe other cases of the general "adding imples breaks inference/defaulting" too, like adding `impl Index<u8> for [T]`?
- Default values for generic parameters, or a similar mechanism allowing us to evolve function signatures in a backwards-compatible way. For instance, changing a concrete type to a generic implementing a given trait, but ensuring that inference doesn't break.
- Inference failures are "allowed breakage", but they still have too much community impact to do lightly, especially for commonly used functions.
- Example: Changing `str::repeat` to return not a `String`, but instead a `impl Something` that's implemented for `String`, `OsString`, and by users' own string-like types.
- Existential types with external definitions: https://github.com/rust-lang/rfcs/pull/2492
(E.g. to pick an allocator impl, or a panic impl, or a file system impl, or an async runtime impl, etc.)
- Language alternative for TypeTag hack from https://github.com/rust-lang/rfcs/issues/3192
- Not needing the `&Scope` argument to every thread in https://github.com/rust-lang/rfcs/pull/3184
- More situations where temporaries get lifetimes extended.
- E.g. https://github.com/rust-lang/rust/issues/86845#issuecomment-952322578
- Multiple `#[unstable]` tags on the same thing. E.g. when `Saturating` is unstable, and `.reverse_bits()` too, and that needs to depend on both issues, so it doesn't get stabilized when only one of them gets stabilized.
- https://github.com/rust-lang/rust/issues/93346 might benefit from having two feature flags as well
- Feature requested in https://github.com/rust-lang/rust/issues/94770
- Sealed traits.
- Stabilizing something like stability markers (`#[unstable]`) for use in third-party crates (requiring an opt-in).
- Feature flags would work, but wouldn't have the strong "this is exempt from semver" convention.
- This should have some kind of top-level control, to prevent a random dependency from opting in on a sub-dependency without the top-level crate's knowledge.
- cfg accessible, or at least a subset of it that works for paths from core/alloc/std (e.g. "only paths that start with `::` and an external crate name")
- Some combination of lang and compiler machinery to let us have target-feature-optimized versions of some functions (whether compiler-optimized or hand-optimized with asm) in std/alloc/core, supporting both compile-time optimization (based on features chosen by the user) and runtime selection without a detection conditional on every call
- support for emitting glibc-hwcaps libraries (dynamic link time selection of optimized functions)?
- Defining inherent functions on built-in types (e.g. slices) without requiring lang items for every imp block. (Not sure if this is lang or compiler.)
- A clear future path towards a specialization mechanism that doesn't feel dangerous to use.
- One of many examples: we currently have a stable `Termination` impl for `Result<T, E>` where `E: Debug`, but it'd be nice to have a specialization for `Result<T, E>` where `E: Error`, which would let us use things like the `provide_any` API to retrieve more information about the error (including potentially an `ExitCode`).