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), tmandry (1), BurntSushi (8), joshtriplett (12), dtolnay (3), nikomatsakis (1), yaahc (3), pnkfelix (1), Amanieu (12), scottmcm (1)

(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.

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