# Libs Meeting 2022-10-19

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

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

## Triage

### [backport] rust.tf/102760 *Avoid repeated re\-initialization of the BufReader buffer*

accepted.

### rust.tf/89058 *Drop support for FreeBSD 10 from std*

We might want to drop 11 too. 11 EOL was in 2021.

Which team makes the decision?

- according to the policy: compiler + infra
- but dropping an older version isn't much of an infra thing. it seems more of a libs+compiler thing.
- let's do this as a libs+compiler FCP

### rust.tf/102766 *Don't link to \`libresolv\` in libstd on Darwin*

We don't use libresolv (anymore), so we can remove it from libstd. But that might break programs that accidentally rely on this library being linked in. (If they forgot to link it themselves.)

Seems fine to change this.

## const in the standard library

Context: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/const.20in.20the.20standard.20library/near/301868649

Const experimentation is ongoing, but it isn't very ergonomic yet. Folks are constifying things in the standard library based on capabilities, without waiting for ergonomics. There isn't an easy technical rule we could apply here, this is more of a social issue.

Tradeoffs between how much something reduces ergonomics and how much value something adds.

Concerns:

- Maintainability.
- Some things get a lot more verbose. (E.g. manual trait impls, or expanding a closure to a separate function, etc.)
- Upgrading to a new beta.
- Making changes becomes harder when we have to take `const` restrictions into account.
- Making it harder for a simple bug fix etc.
- Adding something to a trait can become harder or impossible, if `const` adds more restrictions.
- It can make contributing harder. We might even have to say no to certain changes if they don't fit with the `const` restrictions of a trait. :(
- Risk of accidentally making some new const stuff available on stable.
- Easy to 'expose' a dependency on something being implemented (e.g., const sort feels 'easy' but maybe depends on partially const traits for the Ord/Eq impls, etc.)
- Unfamiliar/unstable syntax in the rust standard library.
- E.g. users clicking `[src]` in rustdoc will see unfamiliar syntax.
- Also makes contributing harder.
- Copy-pasting from the standard library (e.g. for benchmarks or experiments) would require (more) unstable features and unfamiliar syntax.

We should add this to the std-dev-guide.

We should document a policy that something that impacts the above points should include a strong justification, and what the alternatives are. And perhaps what the future plans are. E.g. `~const Destruct` is temporary, but what's the plan to get rid of it?