# Libs-API Meeting 2023-03-07

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

### (nominated) github.com/rust-lang/libs-team/issues/62 *ACP: \`PathLike\` trait*

Discussed last time. New updated proposal now.

New proposal: A sealed `AsPath` proposal to replace `AsRef<Path>`, and a `NativePath` type. Both unstable to allow for experimentation, but `AsPath` will show up in the documentation.

Fairly confident that it won't break anything, since many things already implement `AsRef<Path>`. Just the beta crater run should be enough.

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

Skipped this meeting.

### (nominated) rust.tf/81872 *Tracking Issue for Mutex::unlock()*

See also https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/stabilizing.20Mutex.3A.3Aunlock.28.29

Some discussion on Mutex::with(|| ..):

- Using closures doesn't play well with `return`, `?`, `break` etc. etc.
- Use blocks instead. Add to Mutex examples.

Back to `Mutex::unlock()`:

- David: we have this at google. The issue was drop()'ing the wrong thing. E.g. dropping a &MutexGuard instead of a MutexGuard.
- Clippy's drop_ref lint catches that.
- Should be a rustc lint instead of a clippy one?

Using Mutex::unlock() in some strategic cases can be useful for making the code more readable, but in many cases it might make things worse, resulting in a net negative.

dropping things to release resources is pretty fundamental to Rust.

two ways of doing things is bad for learnability.

Let's close, but also let's get a lint for drop()'ing the wrong thing.

The drop_copy lint might have false positives if people use drop() for #[must_use].

### (nominated) rust.tf/97594 *Implement tuple\<\-\>array convertions via \`From\`*

Asked for use cases last week. Got an example of (r,g,b) to [r,g,b].

Seems fine.

Error in the test cases gets verbose. Let's check if there's already an open issue for that.

### (nominated) rust.tf/99929 *Implement Default for some alloc/core iterators*

See https://github.com/rust-lang/rust/pull/99929#discussion_r1120440873

David also agrees.

### (nominated) rust.tf/107200 *io: soften ‘at most one write attempt’ requirement in io::Write::write*

Un-nominated.

### (nominated) rust.tf/107276 *Windows: Path API Incorrectly Handles Alternate Data Stream Identifiers*

No other language seems to handle this properly.

Our `Path` type has quite a few problems.

Tangent: Path::components() is a source of quite a few API problems, but nearly all usages seem better served by a dedicated method.

A better design seems possible, but none of us seem to have the time for that.

Let's collect issues with the Path API and form requirements for a new one, and put out a call for a new design.

Mara to tweet and make a hackmd.

### (nominated) rust.tf/rfc3240 *Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods*

Lang team wants to know from libs-api first if we want this at all.

Josh started FCP, but nobody else checked their checkbox yet.

Mara: This shouldn't be tied to editions. rust-version or something similar seems better.

[much discussion]

- This RFC never introduces a new error that didn't already occur before this RFC. It turns the existing error into a warning if you're not in the next edition after the method was introduced.

### (nominated) rust.tf/rfc3362 *Command improvements for ergonomics and error handling*

### (nominated) rust.tf/rfc3394 *format\-dynamic\-fill*

### (waiting-on-team) rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`*