# Libs-API Meeting 2023-02-28

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

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

## Agenda

- Project update: [governance RFC](https://github.com/rust-lang/rfcs/pull/3392)
(Please take a look and leave comments if you have it.)
- Council representative
Libs (as a whole) will need to select a representative (if this RFC gets merged in its current form)
- Trustworthy HashMaps (`RawEntry`, etc)
- Triage
- Anything else?

## Trustworthy HashMaps (`RawEntry`, etc)

Recently we discussed how one can trust that e.g. `BinaryHeap<u32>` is always in the right order.

Does that mean that the RawEntry api should be unsafe/non-existent?

We might just not expose this in std, and redirect people to hashbrown (etc.) for these use cases.

Inconsistent Hash for HashMap means items that show up in iteration, but can't be looked up. (Different than an inconsistent Ord for BTreeMap or BinaryHeap, where the iteration order is unexpected.)

PR that adds docs, and do an FCP on that?

Seems already documented publicly. To be discussed on the tracking issue.

## Triage

### FCPs

1 rust-lang/rfcs T-libs-api FCPs

16 rust-lang/rust T-libs-api FCPs

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

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

`PathLike` trait. Replacement for `AsRef<Path>` so you can use native types. (E.g. UTF-16/UCS-2 on Windows.)

`NativePath` would have to be different for each platform. Still an open question.

`with_native_path` would have a default impl that calls `with_path`, which can work as a (not necessarily optimal) fallback.

Should some custom `Utf16Path` type be usable on all platforms? (By converting through `with_path`?) Or should such types be platform specific?

Amanieu: What if we make PathLike a sealed trait in std, and expose a NativePath?

NativePath could just be a type alias to &CStr.

For Windows we don't have a type for NativePath yet. (Vec\<u16\> doesn't guarantee zero-termination.)

Note that &CStr currently knows its own length, but it should be a thing pointer instead when &CStr is fixed.

Josh: We could _start_ with PathLike as a sealed/internal trait to allow more than just `AsRef<Path>`, and maybe expose it later.

Just making `NativePath` an alias is bad for portability.

Main question seems to be the design of the `NativePath` API.

The 8472: Are there any programs where this is the bottle neck though? All usages do a syscall anyway. Might not be worth increasing the API surface.

Mara: We should also look at functions that give paths as output rather than take them as input. E.g. directory listing of readlink etc.

Mara: It's not just performance, also binary size.

Taking a NativePath in File::open etc. means you can know it won't panic on an allocation failure. (Since it wouldn't allocate.) This makes it usable if you can't assume infallible alloc.

For experimentation, we can do this unstably, if the AsRef -> PathLike change doesn't break things. That will unlock experimentation outside std.

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

Zero length conversion ([] -> ()) breaks some interferrence things, but we can leave it out.

Do we have a good use case for these?

Asked for use cases.

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

FCP finished.

scottmcm commented:

> Hello @rust-lang/libs-api folks! This PR, as currently written, allows `<Fuse<u32>>::default()` but not `<Rev<u32>>::default()`. That feels unintentional, so nominating for a decision on what the intent was here -- notably there wasn't an API summary in the FCP so it's hard to know for sure.
>
> Do you want:
> - The current state of the PR
> - The adapters to be `Default` only when wrapping iterators
> - The adapters to be `Default` when wrapping any inner type that's `Default`

Mara: last option seems good, since we usually go for the most relaxed bounds possible. and more compatible with derive(Default).

The 8472: That would allow constructing adapters that couldn't be constructed before.

Anyone opposed to option 3? *silence*

(We should confirm with the ones not present, though. Maybe just restart FCP.)

Mara to leave a comment.

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

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

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

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

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

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

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