# Libs-API Meeting 2023-01-17

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: David, Josh Triplett, Mara, The 8472, Chris Denton

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

[m-ou-se (9)](https://rfcbot.rs/fcp/m-ou-se), [BurntSushi (11)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (4)](https://rfcbot.rs/fcp/dtolnay), [joshtriplett (6)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (5)](https://rfcbot.rs/fcp/Amanieu)

1 new RFC FCP:

- merge rust.tf/rfc3240 *Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods* - (8 checkboxes left)

### github.com/rust-lang/libs-team/issues/122 *Revamp unstable MaybeUninit APIs*

Left a new comment.

[const {}; N] stabilization still has ongoing discussion.

### github.com/rust-lang/libs-team/issues/165 *Figure out what to do with {:x?}*

Use cases for {:x?}?

- Structs with integer fields that should always be formatted as hex. (#[debug(x)] maybe?)
- Lists/vecs/arrays formatting with a format specifier for the elements. (`{:?{:x}, }` or something?)
- Same for maps etc?
- `.dbgfmt(|e| format_args!("{e:#x}")`

We should get more data.

Block things like `{:b?}` and so on for now? Yes. It might make the problem worse, and also there should be more motivation than just 'consistency'.

Is Debug output stable? We are allowed to change it, but should be? It can affect lots of code.

We could deprecate the `x` and `X` flags on `?` in format_args!() if we have a better alternative.

Action: Ask if someone can gather more data on use cases, and propose a solution.

Multi-level formatting sounds like something we might want to add.

Mara to leave a reply.

### rust.tf/54140 *Tracking Issue: Procedural Macro Diagnostics (RFC 1566)*

No updates. (David busy with syn 2.0.)

### rust.tf/87053 *Tracking Issue for Iterator::try\_reduce (feature iterator\_try\_reduce)*

- Try isn't stable yet.

- Will we get `try_` versions of every single method?
- Josh: Lang has no solution for this. If someone has a solution for this, please propose it!
- David: `try_reduce` seems more foundational than e.g. `try_all`.
- The 8472: isn't `try_reduce` just a convenience function for `try_fold`?
- Also, motivation is missing.

`try_reduce` uses `Reduce` etc., while `try_fold` uses only `Try::Output`.

A new Try design might change the meaning of turbofish syntax.

Josh to reply.

Some discussion about a hypothetical lang feature to have control flow cross closure boundaries.

David: types wouldn't need to override `try_reduce` (only `try_fold`), so we could separate it from the Iterator trait.

### rust.tf/102697 *Stabilize \`ControlFlow::{BREAK, CONTINUE}\`*

Nobody in favor of keeping this.

FCP close. Josh to reply and start fcp close.

### rust.tf/103702 *Lift \`T: Sized\` bounds from some \`strict\_provenance\` pointer methods*

Looks good. Gankra also said it's good.

No objections in the meeting. Mara approved it.

David: When could we stabilize these methods?

We can probably move this forward, FCP might go through at this point.

### rust.tf/106441 *relax reference requirement on SocketAddrExt::from\_abstract\_name*

Josh happy to r+ if there are no objections.

Unstable. Looks good.

### rust.tf/106643 *Allow only implementing \`Read::read\_buf\`*

Seems fine. But we should be careful not to stabilize read_buf before stabilizing the 'implement one of' attribute.

David: What happens with error messages? The compiler shouldn't suggest implementing read_buf. Since that's unstable, it should only mention `read`.

Worth blocking on that.

Some discussion about behavior of diagnostics and rust-analyzer. (Should it always prefer `read` over `read_buf`? Suggesting both could be noisy and not a great experience for beginners.)