# Libs/Lang interop

Attendees: tmandry, eholk, josh, jpratt, christian denton, dtolnay, amanieu, yosh, tgross35, .., ..

## Introduction

Josh: <explaining why we're here>

tgross35: Someone from compiler asked if we want unstable trait impls? https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/unstable.20.28feature-gated.29.20impls/with/518818143

(room): Yes, very much

## Initial list of candidate items

Josh: on the list for today are:

- try blocks
- Avoid writing helpers/combinators
- Knowing when this is coming, or *if* this is coming, affects our decisions for adding future things, and reducing future cruft
- Could soft deprecate a lot of the helpers. Case study: `Error::description()` soft deprecation worked well.
- try trait
- instability has made us hesitant to return/accept an `impl Try`
- In particular also the `Residual` feature
- once_lock, lazy_lock initializers examples of things that want this
- david: may or may not be blocking, we may not want to use it. Signatures can become unreadable when using them.
- josh: Is there a lang feature that would make this more readable/usable? e.g. "try functions"
- Outcome: Might be blocking but unclear
- super trait item shadowing
- RFC merged and implemented in nightly
- could be close to stabilizing
- Actively blocking us from adding new methods to the standard library
- Blocking Iterator::intersperse and Iterator::contains; others we might want to add
- implementing super trait via subtraits
- this would allow us to move parts of a supertrait into the subtrait, breaking theem up/making them more fine-grained
- Not actively blocking but could block larger scale work people might want to, e.g. numeric traits hierarchy
- Having commitment it is coming would make us comfortable shipping things that might need it in the future
- two defaulted methods implemented in terms of each other, forcing you to implement one or the other
- read and read_buf
- In some cases we want to encourage you to implement one instead of the other (e.g. which one should IDEs make a template for)
- Not used yet, should be
- inherent traits
- useful for a collection traits like `has` or `Insert` that want to exist on e.g. hashmap
- useful to pull methods out of existing things that have them
- would not be useful to shrink the size of Iterator, but other features in this list might be
- library editions
- Yes, please enable us to make bigger breaking changes
- example: mutex; swap the default implementation (path) of Mutex over an edition
- May need some careful design around implications with name resolution (and macros)
- delegation
- some folks want it to write little wrappers (e.g. newtypes)
- jpratt: there is the `reuse` keyword that has been implemented. there is a tracking issue for that
- tg: maybe not blocking much in libs, a lot of things that would be delegated (e.g. sys) still need some kind of extra details in the wrapper function
- Not needed anytime soon
- some subset of effects to solve the `try_map` problem
- you need the `map`, `try_map`, `async_map`, `async_try_map`
- Same problem with allocation methods, need a panicking version that can't return an error, and a `try_` version that can return an error
- Currently blocking adding other methods because we're hoping for something better
- externally implementable items, e.g. for target feature detection for CPUs in core
- on x86 you can call `cpuid` and be done, other cpus require more involved APIs that don't work for `core`
- Amanieu: last I heard implementation is in progress, and it should be done in about a month
- Stuff like global_allocator
- Defaulting/fallback for float literals, blocking the stabilization of f16, because it breaks inference of e.g. passing `1.0` to a function taking a generic parameter
- tgross: blockers to stabilization of the type itself mostly on the llvm side. we could skip the trait impls for now.
- amanieu: could we tweak fallback, e.g. so it prefers the identity impl for `Into` in cases of ambiguity?
- tgross: it would sometimes be nice if we could use `Into` on bitwise operations
- josh: type inference is a difficult topic
- tmandry: Types team is starting to think about this
- tmandry: anytime you use `AsRef`, it kind of feels like a bug in the language
- josh: esteban has a lint in progress if you ever rely on `impl Into<T> for T`
- David: clippy already has this implemented. Unsure whether it handles the edge case of ctypes/type aliases
- dtolnay: We have to have impls for each pair of types, e.g. `Add<u8> for u8`, `Add<u8> for &u8`, `Add<&u8> for u8` ...
- tmandry: Essentially an implicit coercion feature.
- tgross: why can't we use `AsRef` here?
- josh: you end up conflicting with half the universe's worth of trait impls, and you can't ship things because it ends up matching on too many things. And people who have code that worked before (because there was only one type something could be) end up failing (because there are many possible types that `AsRef<str>`)
- Integer and float literals being a special IntLiteral or FloatLiteral type
- josh: seems to overlap with Oli's pattern types work
- jpratt: overlap, but not entirely
- anonymous enums
- allows you to combine heterogenous types
- Is this a libs-api request?
- room: it isn't
- externally implementable items
- for a global version of spawn or allocator

We should have a standard template for PRs sent to fix crater issues. We should link that template from craterbot's messages about triaging crater issues.

david: would it be useful to segment this list into what blocks libs to ship a better stdlib? (like super trait item shadowing)
josh: yes

## List of items that block

highest priority items, in no particular order:

- unstable trait impls
- super trait item shadowing
- implementing supertraits via subtraits
- library editions
- try trait
- try lang feature: unclear, might be
- some form of effects would be good to have
- maybe-try + panicking/allocating variants for all functions are a lot