# Libs Meeting 2021-12-15

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi
**Attendees**: Amanieu, Jane, Josh Triplett, Josh Stone, Mara, Mark, The 8472

## Agenda

- [Open Action Items](https://hackmd.io/Uehlc0qUQfWfvY1swYWRgQ)
- Triage
- Roadmap / wishlist - brainstorm
- Anything else?

## Triage

### FCPs

None

### Critical

None

### Backports

None

### Prioritization Requested

None

### Nominated

- [1 `rust-lang/rust` `T-libs` `I-libs-nominated` items](https://github.com/rust-lang/rust/issues?q=label:T-libs+label:I-libs-nominated+is:open)
- [[88714](https://github.com/rust-lang/rust/pull/88714)] *use CLOCK\_BOOTTIME in Instant::now*
- On windows: getting time uses 'boottime', but sleeping uses 'monotonic'. so it's not as simple as 'windows always uses boottime'.
- Multiple clocks, with different types for them?
- Only for Instant, not for Duration.
- We currently document the current behaviour in detail (exact functions that are used).
- Undone the fcp-merge result for now.

### Regressions

None

### Roadmap / Wishlist - brainstorm

There are plenty of ongoing API proposals and PRs, but everything else library-related could probably use some more overview or direction.

Let's talk about what we'd ideally like to see happen next year. Not to set deadlines, but to have some directions to work towards. As an inspiration for what people can work on.

- Improved implementations of {anything}
- Mutexes and condition variables
- parking_lot or similar into std?
- mpsc
- (improve or deprecate)
- replace with flume?
- Deprecate and make recommendations?
- std::fmt (code size?)
- `Allocator` API
- ...
- ...
- Unwinding support for no_std
- This now possible with the `unwinding` crate but requires several nightly features.
- Can we support this functionality in a stable way?
- Platform/operating system support?
- Supporting out-of-tree platform/system implementations.
- "Does anyone know what Hermit is?" exactly
- Stable interface between `std/sys` and `std` would be very hard
- But do we do that? Can the entire `std` be a crate on crates.io, so people can have their own std for their own platforms?
- `std` and compiler versions need to match. std uses tons of nightly features, many of which only work on one specific version of rustc.
- Could we do with less nightly features?
- We have a ton of `cfg(..)` for os-specific stuff oustide of `sys/`.
- `core` will always need nightly/unstable features, but maybe `alloc` and `std` can become stable at some point.
- Official rust-lang crates?
- Semi-official crate recommendations?
- rand
- put getrandom into std
- error handling improvements (Jane: roughly prioritized by personal view of best prioritization)
- integrating Error trait with panic
- unwrap() report as &dyn Error, print sources, not `Debug`
- `ThinBox<dyn Error>` support that has a proper `Error` impl
- error handling stabilizations (Termination, Try, Chain, Generic Member Access, Error in core)
- Book / documentation, crate recommendations, practical examples of error handling patterns
- Error derive in std
- Error return traces (support capturing locations from every `?`)
- anyhow/eyre-esque "any error" wrapper in std/core?
- Jane: Less eager about this one atm
- Josh: I think this is just the `ThinBox<dyn Error>` item mentioned above?
- In my mind `anyhow`/`eyre` are largely about adding more substantial reporting facilities, or at least eyre is, anyhow would be mostly equivalent to ThinBox + std::error::Report, except that anyhow guarantees backtrace capture
- I'm looking for the ergonomic/efficient equivalent of `Box<dyn Error>`, not an extensive set of helpers and reporting infrastructure. (Happy to use the context/cause chaining bits being added to Error, rather than something custom.)
- Sounds like a plan, ThinBox would cover those needs afaik
- `type SomethingError = ThinBox<dyn Error>` + `type Result<T> = Result<T, ThatError>` ?
- `DynError` + `DynResult`?
- :+1:
- Actually, the DynResult would need to be an independent type, because of `Try` trait impl on std result not being compatible with the Error impl on ThinBox
- We should talk more, asynchronously, about that. Not obvious why that isn't an issue with `anyhow::Result<T>`.
- Because `anyhow::Error` doesn't impl `Error`
- Do we need `DynError` to impl `Error`? (Though it *is* a pain that anyhow::Error doesn't.)
- I believe so, you can work around it like we do currently, but I think thats an unideal situation
- FFI types in `core`? `c_ulong`, etc.
- (`core` can depend on OS types? it's part of the target triple. and if there's no C compiler/abi for it, it doesn't matter much?)
- https://github.com/rust-lang/rust/compare/master...Amanieu:core_ctypes
- Last updated in 2018, very out of date.
- Refactoring? General maintenance?
- CI should run stage0 std tests to make sure compiler changes don't break stage0 workflows
- Testing is annoying, since we only test linux in CI.
- A `check` of all platforms for std might be useful.
- compiler_builtins: better implementations of float stuff.
- Wild idea: improving/integrating libc crate?
- Some changes require updating libc before updating std, which is annoying. Is there enough value in keeping them separate? (Subtree?)
- even if we don't do this for libc, we can do it for compiler_builtins?
- -Zbuild-std related stuff
- Only reason to not do it would be build times, but that's an issue you have with all dependencies. Some caching solution would help.
- We need a concept of unstable feature flags.
- Going one step further: what would it take for std to be "just another crate"?
- Documentation?
- standardized notes (normative vs. non-normative). macros?
- too many examples? trim it down?
- some effort towards highlighting important traits, etc. things easily get lost. would also need support from rustdoc.
- documentation for pointers to slices is on pointers, not on slices.
- Merging core+alloc+std?
- allow SIMD to be used in what's currently core
- would have helped with Error in core but the issue has been worked around via lang items
- Growing libs team review capacity / team size
- metrics to guide when this is necessary
- Safety documentation / UCG involvement
- Help Rust for Linux (kernel)
- building their own version of alloc (and core?). but that sounds bad.
- Work with lang team, tell them what we could use to improve our lives.
- Language feature wishlist
- https://github.com/rust-lang/rfcs/pull/2492
- Helps to reduce the use of lang items in the standard library
- +1 - this would also enable things like async runtimes

..

## Actions

- [ ] Reply to all issues/PRs discussed in this meeting, or add them to the [open action items](https://hackmd.io/Uehlc0qUQfWfvY1swYWRgQ).

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_