# Libs-API Meeting 2023-11-21

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/52331 *Correcting Path::components on Redox* - (5 checkboxes left)
- merge rust.tf/82901 *Tracking Issue for \`Option::get\_or\_insert\_default\`* - (2 checkboxes left)
- merge rust.tf/83871 *Tracking Issue for CharIndices::offset function* - (3 checkboxes left)
- merge rust.tf/117824 *Stabilize \`ptr::{from\_ref, from\_mut}\`* - (4 checkboxes left)
- merge rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`* - (4 checkboxes left)
- merge rust.tf/106655 *Tracking Issue for \`#!\[feature(offset\_of)\]\`* - (0 checkboxes left)
- merge rust.tf/62726 *Tracking issue for io\_slice\_advance* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (0 checkboxes left)
- merge rust.tf/76118 *Tracking Issue for \`array\_methods\`* - (3 checkboxes left)
- merge rust.tf/109402 *Implement owned ops for \`HashSet\` and \`BTreeSet\`* - (4 checkboxes left)
- merge rust.tf/116113 * Generalize \`{Rc,Arc}::make\_mut()\` to unsized types.* - (4 checkboxes left)
- merge rust.tf/113833 *\`std::error::Error\` \-\> Trait Implementations: lifetimes consistency improvement* - (3 checkboxes left)
- merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (3 checkboxes left)
- merge rust.tf/93610 *Tracking Issue for \`arc\_unwrap\_or\_clone\`* - (3 checkboxes left)
- merge rust.tf/101288 *Tracking Issue for \`{char, u8}::is\_ascii\_octdigit\`* - (3 checkboxes left)
- merge rust.tf/117468 *Stabilize Wasm relaxed SIMD* - (5 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (2 checkboxes left)

[m-ou-se (10)](https://rfcbot.rs/fcp/m-ou-se), [tmandry (1)](https://rfcbot.rs/fcp/tmandry), [BurntSushi (8)](https://rfcbot.rs/fcp/BurntSushi), [joshtriplett (12)](https://rfcbot.rs/fcp/joshtriplett), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [nikomatsakis (1)](https://rfcbot.rs/fcp/nikomatsakis), [yaahc (3)](https://rfcbot.rs/fcp/yaahc), [pnkfelix (1)](https://rfcbot.rs/fcp/pnkfelix), [Amanieu (12)](https://rfcbot.rs/fcp/Amanieu), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm)

### (nominated) rust.tf/93346 *Tracking Issue for panic\_backtrace\_config*

Discussion last week resulted in a question.

Reply to question is a question.

To be resolved/discussed on the tracking issue first before we can consider stabilizing.

### (nominated) rust.tf/105135 *Tracking Issue for \`file\_create\_new\`*

FCP finished. Should be merged?

Question popped up during FCP:

> File::create returns a file in write-only mode but File::create_new returns a file in read-write mode. What is the reason for this difference?

Originally added by Josh: https://github.com/rust-lang/rust/pull/98801/files

Josh: Perhaps File::create should have had read access to.

Josh: For creating a new file, there's no reason to not have read access to your new file.

The 8472: Can you later drop read access?

Josh: For a pipe that makes sense, but for a file (through which one can seek and write) it doesn't make much sense to deny reading.

Mara: Are there any downsides? (Consumes more resources or something..?)

Josh: Not as far as i know.

Mara: So, continue with this FCP as is?

Josh: Happy to document it.

David: What would break if we change File::create to use read+write mode as well?

Josh: Theoretically, nothing. But maybe an operation that you'd expect to return an error would start to succeed.

Josh: I can imagine a scenario: You call File::create to open a file that already exists, you can use it to open a pipe/fifo/something where it's meaningful that it's write-only.

Josh: File::create is roughly equivalent to `>` in the shell.

Josh: Changing File::create to do read+write would break when opening a file that isn't a regular file.

The 8472: Imagine a scenario where a process isn't supposed to read what others are writing to the file, but is allowed to overwrite anything it wants..

Josh: unlikely, but yes.

Mara: Equivalence to `>` is probably important for at least some Rust projects. There are shells implemented in rust that might break if we change it.

Josh to post a comment on the tracking issue to answer the question.

David: How about BurntSushi's question: is this operation common enough to warrant its own method?

Mara: I think so yes. I think that File::create_new is more common than File::create. (Forcing the "create or truncate" operation (File::create) to go through OpenOptions would make more sense than for "create new", imo.)

David: Ok. Let's make sure to capture that on the tracking issue.

Josh: I'll add it in my comment.

David: Is there a stronger "create or overwrite" operation that would even work to remove/overwrite a directory?

Josh: no

### (nominated) rust.tf/115386 *PartialEq: handle longer transitive chains*

Why did #81198 change it?

Before that PR, PartialEq impls were required.

Now, it's possible in a `a == b == c == d` chain for there to be no PartialEq impl
between `A` and `C` but still have it for A+B and A+D.

David: Fine with merging this.

Mara: Didn't we have a counterexample based on JsonValue and comparing it to integers and floats?

David: Don't rememnber that.

David: There is a cross-crate issue where another crate could add a PartialEq impl that break these rules of your PartialEq impl.

Mara: `f32 == json::Value == i32 == bson::Value`. If 1f32 and 1i32 are equal in JSON but unequal in bson, that is a violation.

The 8472: Wouldn't this require PartialEq between json and bson?

Mara: Nope.

David: Right, Ralf's proposed wording says at least one of these impls is faulty.

David: Perhaps the rule should also require PartialEq between the others (A+C and B+D).

Mara to post this example and ask for Ralf's thoughts on it.

### (nominated) rust.tf/117658 *rename ptr::invalid \-\> ptr::dangling*

`ptr::invalid` is still unstable. `NonNull::dangling` is stable.

The 8472: NonNull::dangling already exists, and has additional guarantees and a different signatures.

David: What's the guarantee?

The 8472: Alignment.

scottmcm: NonNull::dangling becomes NonNull::new_unchecked(ptr::dangling(T::Align))

Also <https://doc.rust-lang.org/std/alloc/struct.Layout.html#method.dangling> (unstable)

Mara: ptr::invalid is part of the strict provenance effort.
it's basically ptr::without_provenance. (Not saying we should use that name.)

Mara: Ralf suggests `dangling` and `dangling_with_addr`. Could make sense, since the latter would be equivalent to `dangling().with_addr(_)`.

Mara: That would be too verbose right?

the 8472: we don't have dangling on ptr

Mara: Yeah, we'd add that. Then it'd be equivalent to NonNull's dangling()

David: That's a really good idea.

Mara: Very verbose though.

David: And dangling_mut(). Or rely on coercing. Not sure if we do that anywhere else.

Mara: `*const` vs `*mut` in Rust today is weird.

:+1: all around

The 8472: The PR is motivated by "invalid" being misleading for ZSTs. If the main use case is to smuggle integers into pointers, then that's fine, right? Maybe the current name is fine for the main use case?

Scott: The iterator example was also just smuggling an integer through a pointer type, so there 'invalid' seems right too.

Mara: Looks like we're not reaching a conclusion. Can we conclude we do *not* want ptr::dangling(usize), since it's inconsistent with NonNull?

David: I think all options are fine, including invalid(addr), dangling(addr), dangling().with_addr(addr), dangling_at, etc.

Scott: for dangling().with_addr().. null().with_addr() works fine.

Mara: Ask for an overview of actual use cases of ptr::invalid today?

Mara to ask for use cases.

### (nominated) rust.tf/118108 *PartialOrd: transitivty and duality are required only if the corresponding impls exist*

Related to the PartialEq discussion.

Mara: Probably good to finish the PartialEq discussion first.

David: Not a prerequisite. This is catching up to where PartialEq is today.

The 8472: It is also more.

David: Let's check next week.

### (new change proposal) rust.tf/libs293 *\[ACP\] IO traits in \`core::io\`*

### (new change proposal) rust.tf/libs294 *Add get\_mut\_or\_init and get\_mut\_or\_try\_init for OnceCell*

### (new change proposal) rust.tf/libs295 *Create iterator function in std libs: split\_item\_mut()*

### (new change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`*

### (new change proposal) rust.tf/libs297 *Sugar for special\-casing last iteration*

### (stalled change proposal) rust.tf/libs131 *Add \`std::fs::rename\_noreplace\`*

### (stalled change proposal) rust.tf/libs164 *Add methods for use cases that \`align\_to\` does not cover*

### (stalled change proposal) rust.tf/libs155 *Arbitrary alternate flags in \`std::fmt::Formatter\`*

### (stalled change proposal) rust.tf/libs124 *Integrate \`Error\` trait with panic interfaces*

### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_