Libs Meeting 2020-11-11

# Libs Meeting 2020-11-11 ###### tags: `Libs Meetings` `Minutes` ## Agenda - Project group updates - T-libs vs libs-impl and the role of library-reviewers - Missing guidelines - Triage - Anything else? ## Missing guidelines Things that could use a guideline, because they keep coming up. This doesn't need to be discussed in detail right now. But we should at least discuss how/where/when to address these. - When to use `#[must_use]`: [[48926](https://github.com/rust-lang/rust/issues/48926)] [[78225](https://github.com/rust-lang/rust/pull/78225)] [[71256](https://github.com/rust-lang/rust/pull/71256)] [[66116](https://github.com/rust-lang/rust/issues/66116)] [[api-guidelines 226](https://github.com/rust-lang/api-guidelines/issues/226)] - When to use `Pin`. [[77726](https://github.com/rust-lang/rust/pull/77726)] [[77801](https://github.com/rust-lang/rust/pull/77801)] [[78370](https://github.com/rust-lang/rust/pull/78370)] - How to handle tier 3 sys changes. \ These are usually accepted without review. Should we at least ping the 'owner' of that platform? Is there a list of contacts for these platforms? - How careful we should be with *unstable* changes. \ (E.g. `Duration::zero()` -> `Duration::ZERO` or removing/breaking `std::io::set_panic`.) ## Triage Issues with a `I-nominated` label have been flagged for discussion. **FCPs** Open FCPs: https://rfcbot.rs/ \ ([Amanieu](https://rfcbot.rs/fcp/Amanieu), [BurntSushi](https://rfcbot.rs/fcp/BurntSushi), [dtolnay](https://rfcbot.rs/fcp/dtolnay), [KodrAus](https://rfcbot.rs/fcp/KodrAus), [m-ou-se](https://rfcbot.rs/fcp/m-ou-se), [sfackler](https://rfcbot.rs/fcp/sfackler), [withoutboats](https://rfcbot.rs/fcp/withoutboats)) - [`rust-lang/rust` FCPs](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-libs+label%3Aproposed-final-comment-period) - [[64260](https://github.com/rust-lang/rust/issues/64260#issuecomment-723050764)] *`bool::then(..) -> Option` (and `then_some`?)* \ FCP already happened twice, both blocked by a concern about `then_some` (and naming in general). withoutboats now suggested only stabilizing `then` and not `then_some`. Needs confirmation/checkmarks from KordAus, sfackler, Amanieu, dtolnay. - [`rust-lang/rfcs` FCPs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+label%3AT-libs+label%3Aproposed-final-comment-period) **Nominated** - [`rust-lang/rust` items](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-libs+label%3AI-nominated) - [[76041](https://github.com/rust-lang/rust/pull/76041)] *impl ops::Try for Ordering* \ This implements `Try` for `Ordering`, such that you can use `?` to return a non-`Equal` result right away. This is often useful, but it seems to do the exact opposite of what `?` does on an `Option` (returning the 'some' instead of the 'none'). - [[78618](https://github.com/rust-lang/rust/pull/78618)] *Add IEEE 754 compliant fmt/parse of -0, infinity, NaN* \ Changes the way `-0` is printed. Currently `format!("{}", -0.0) == "0"` and `format!("{:+}", -0.0) == "+0"`. This changes *both* to `-0`. (And some discussion about printing `-0.0` instead.) - [`rust-lang/rfcs` items](https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+label%3AT-libs+label%3AI-nominated) - [[RFC 2996](https://github.com/rust-lang/rfcs/pull/2996)] *async `Stream` trait* **Waiting on team** - [`rust-lang/rust` items](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-libs+label%3AS-waiting-on-team) - [`rust-lang/rfcs` items](https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+label%3AT-libs+label%3AS-waiting-on-team) **Needs decision** - [`rust-lang/rust` items](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-libs+label%3AI-needs-decision) - [[74699](https://github.com/rust-lang/rust/pull/74699)] *Mark `-1` as an available niche for file descriptors* \ `Option<File>` will be smaller, but `File::from_raw_fd` will be unsafer. - [[74024](https://github.com/rust-lang/rust/pull/74024)] *Improve slice.binary_search_by()'s best-case performance to O(1)* \ Makes `[T]::binary_search_by`'s behaviour match the description and signature better. Improves performance in many cases. Decreases performance in some cases. Slightly changes behaviour that breaks a few crates. ## Notes - Project Group updates - Backtrace stabilization is still in the same state - We don't feel changes to backtrace formatting needs to block stabilization - Portable SIMD is mostly blocked on compiler work right now, so nothing for Libs yet - T-libs vs libs-impl vs library-reviewers - We set up the library-reviewers team to have a place to give people `r+` who want to work on the standard library without the overarching burden of RFCs - We passed responsibility of implementation maintenance to the compiler team - What do we want to do going forward? - Use library-reviewers as libs-impl. Accept there's still overlap with libs - Shift triage/backlog bonanza into libs-impl and describe this team - `#[must_use]` - We tend to decide these kinds of things on a case-by-case basis in Lang. We can do the same here in Libs - Create a Zulip channel for guidelines discussions - Try revive the API Guidelines - Our forge docs are also a good place for this - More guidance on changes to unstable methods - When is it ok to make breaking changes to unstable features? - Sometimes we're ok with it, sometimes we're not - When to use `Pin` - Usages and new APIs need compelling motivations - Reviewing `Pin` additions is very tricky - The benchmark for usefulness needs to remove unsafe code in real libraries - Let an ecosystem develop outside of `std`. Don't expose new `Pin` APIs pro-actively from `std` - It is ok to experiment with `Pin` internally - Tier 3 platforms - Experts map should include owners for tier 3 platforms so we have people to ping when changes show up - `binary_search_by` - Even if the benchmarks don't show big improvements we're on board with the semantic clean up the change makes - `-0.0` - Don't print the sign for `-0.0` in `Display` unless you ask for it - Don't print `-0` as `+0` if you do ask for a sign Do another triage next week to work through more of our open issues.