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.
  • 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.
  • 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).
Select a repo