---
# System prepended metadata

title: Libs Meeting 2020-11-18
tags: [Minutes, Libs Meetings]

---

# Libs Meeting 2020-11-18

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

## Agenda

- Triage
- Anything else?

## 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)
  - [[78634](https://github.com/rust-lang/rust/pull/78634)] *Implement PartialEq for proc_macro::Ident == strings*
    FCP already started, but petrochenkov has [a concern](https://github.com/rust-lang/rust/pull/78634#issuecomment-726202004) about the recursive PartialEq implementation for references.
  - [[74860](https://github.com/rust-lang/rust/pull/74860)] *[android] Add support for android's file descriptor ownership tagging to libstd*
    FCP finished, but [a concerns](https://github.com/rust-lang/rust/pull/74860#issuecomment-727018292) was raised: `ManuallyDrop<File>` is sometimes used (both in std and in other crates) as a 'BorrowedFile'. This change would break that on Android.
  - (5 more)

**Nominated**

- [`rust-lang/rfcs` items](https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+label%3AT-libs+label%3AI-nominated)
  - [[2979](https://github.com/rust-lang/rfcs/pull/2979)] *Libs Governance*
    Did we want to make some time to look at this in more detail?
  - (1 more)
- [`rust-lang/rust` items](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AT-libs+label%3AI-nominated)
  - [[58957](https://github.com/rust-lang/rust/issues/58957)] *slice::IterMut::as_slice and vec::Drain::as_slice*
    These two functions seem trivial, no open concerns.
    slice::Iter implements `AsRef`, should these too? A [previous attempt](https://github.com/rust-lang/rust/pull/65901) at this [was rejected](https://github.com/rust-lang/rust/pull/65901#pullrequestreview-314591255).
    `vec::Drain::as_slice` is now stable and `vec::Drain` implements `AsRef<[T]>`. These were done in the same PR with a motivation of a generic bound that approximates iterators that can be by-value or by-ref.
  - [[78204](https://github.com/rust-lang/rust/pull/78204)] *impl<A, B> IntoIterator for (A, B) as Zip*
    Concerns about confusing meaning of `(a, b).into_iter()`: Might mean `a.into_iter().zip(b)`, or `a.into_iter().chain(b)`, or `[a, b].into_iter()`, or `a.into_iter().cartesian_product(b)`.
  - [[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').
  - (21 more)


**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)
  - [[76240](https://github.com/rust-lang/rust/pull/76240)] *Add format_to! macro*
    Adds `format_to!(string, ..)` to work around problems with `write!(string, ..)`. *Almost* the same as `write!()`, but does not require `use core::fmt::Write` and does not return a `Result`.
    Alternatives: 1) Allow ignoring the `Result`. 2) New `string::Write` trait. 3) Inherent `String::write_fmt` (breaking). 4) ..?
  - (13 more)
- [`rust-lang/rfcs` items](https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+label%3AT-libs+label%3AS-waiting-on-team)
  - None

**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.
  - (12 more)

## Notes

- 78634: Are we worried about recursive impls in `proc-macro`? Not really. The main concern is around inference failures, which comes up with `==`. Going the other way probably wouldn't work due to coherence rules. We can't add a `PartialEq<str> for Ident`. Worried about consistency, but we'd like to add an overridable impl at some point in the future maybe?
  - [x] [Replied](https://github.com/rust-lang/rust/pull/78634#issuecomment-740890546)
- 74860: This is only really useful for `FromRawFd`, but possible also from `File::open` if we want to then convert that into raw FDs. We don't think we can actually start doing tagging by default without violating the current contract. Let alternatives play out then re-examine.
  - [x] [FCP cancelled](https://github.com/rust-lang/rust/pull/74860#issuecomment-729930256)
- 76505: We're concerned about this appearing a method on `Iterator`. It doesn't make sense for all iterators. We don't really want to add std-algorithm to `Iterator`. We'd be more comfortable with a free-floating function or method on slice.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/76505#issuecomment-740905035)
- 70904: We're concerned about the implementation of `stream_len`. It's non-atomic and describes some new semantic behavior. We'd rather have a new trait for this if we want it. We're ok with `stream_position` though.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/70904#issuecomment-731074080)
- 74304: Ping BurntSushi RE object-safety concern to resolve.
  - [x] [Pinged](https://github.com/rust-lang/rust/pull/74304#issuecomment-740915621)
- rfcs/2477: Close and suggest sending a PR.
  - [x] [Replied](https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372)
- 58957: We're happy to FCP. Looked at the ordering of sending things as a single large PR that gets closed, then submitting the same things in several smaller PRs.
  - [x] [Replied](https://github.com/rust-lang/rust/issues/58957#issuecomment-731069778)
- 78204: We don't want to add this as an `IntoIterator`, but would be ok as a free `zip` function. Does this belong in `itertools`? We'd prefer to pull `itertools` for missing combinators, rather than for free-functions. It would be nice to be able to merge `itertools` into std someday... Free-floating combinators that take a chain of iterators seems fine.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/78204#issuecomment-731079088)
- 76041: Are we ok with `?` on `Ordering`? We have wanted this for `bool`. It would be nice to be able to use `?` for `-> bool`. Is the `?` an unwrapping operator or is it the early-returning `then` operator? Doesn't fit in the current definition of `?` and move discussion over to `lang`. The `?` impls on `Poll` are strange.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/76041#issuecomment-731084839)
- 76240: Do we want to add a macro to fix this papercut? We like the idea of `#[may_ignore]`. We're not super excited about a third trait, but would prefer something like that over a `format_to` impl.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/76240#issuecomment-731097896)
- 74699: First actual concrete reason for `FromRawFd` to be an unsafe trait. If we make `FromRawFd` a safe trait then we contract that _all_ file descriptors are shared volatile state. With a file descriptor you're trusting the outside world not to mess with you ad to behave the way you're expecting. Morally speaking this shouldn't be possible. Would we ever feel comfortable turning the `assert!` into a `debug_assert!`? Similar issue in PR that changed `SocketAddr` to wrap Rust types instead of `libc`. Possibly different though because we unconditionally panic instead of just changing behavior. Start a FCP.
  - [x] [Replied](https://github.com/rust-lang/rust/pull/74699#issuecomment-730293296) and [FCP'd](https://github.com/rust-lang/rust/pull/74699#issuecomment-730310781)

## Outcomes

- Update the current set of reviewers.