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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/88581 *Tracking Issue for \`int\_roundings\`* - (1 checkboxes left)
- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/91946 *Tracking Issue for \`io::Error::other\`* - (3 checkboxes left)
- merge rust.tf/98461 *Document lack of panic safety guarantees of \`Clone::clone\_from\`* - (0 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* - (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/107587 *Mark \`std\` integral modules as deprecated (\`std::u32\`, \`std::i16\`, etc.)* - (4 checkboxes left)

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

### (nominated) rust.tf/73014 *Tracking issue for std::default::default()*

Mara: This has been open for a long time. Time to either stabilize or remove it?

Mara: Remove it? It doesn't seem worth it, and it has some subtle downsides. (E.g. recurison detection, see latest comments.)

Amanieu: Can we expect a lang solution for this any time soon-ish?

The 8472: `use Default::default`?

Josh: Afaik, it's more of an implementation question. Lang would probably be on board with importing trait methods, but implementation might be hard.

Mara: FCP was attempted before in september 2021, but didn't go anywhere.

Josh: That's because we wanted to wait for lang features, but those still didn't happen.

The 8472: If someone writes Default::default a lot, their own macro or own function also solves this, right?

Amanieu: In favor of closing this, push people towards developing the language feature.

Amanieu: I don't think we can do this in a backwards compatible way, with first a free function and later importing the trait associated function.

Josh: Difference would be turbofish, `default::<i32>()` won't work for `Default::default`.

(Non-turbofished default free function isn't possible to express today. `-> impl Default` isn't it.)

Amanieu: FCP postpone and explicitly ask for language proposal.

Mara: What does postpone mean? Rip it out of nightly or keep it? Prefer removing it.

Amanieu: Let's keep it in nightly?

David: Remove it?

Let's close and remove it.

Amanieu to respond.

### (nominated) rust.tf/111884 *Clarify intended use case for From/TryFrom/Into/TryInto*

Discussed in last meeting. Waiting on author.

### (nominated) rust.tf/112423 *std::process:\:Child::kill should not fail if process is terminated on Windows*

FCP started a week or two ago. Label removed.

### (nominated) rust.tf/112858 *Update Android system definitions and add riscv\-linux\-android as tier 3 target*

Mara: This adds a target, but also changes some u32 aliases tot u64, etc. In a deprecated module.

Amanieu: Should've been two PRs

It's breaking, but it seems like it was in a broken state before.

David: Not clear if it was already broken? What about other targets?

The 8472: Seems relevant for all Android targets.

Amanieu: The author is on the Android team at Google.

Mara: The os::android::raw module is deprecated. Depending on usage, we could maybe remove it instead of fixing it?

Mara: On github code search I only find "os::android::raw" in copies of `std` itself.

David: This was deprecated in 1.8. Did that version even support Android?

David: Alternative: We can mark them as `unstable` rather than fully removing them?

Josh: That's still breaking.

David: The delta to getting their code to work again is smaller.

Josh: That sounds like a breaking change with extra steps.

Josh: Prefer just fixing the types.

Mara: Sounds good to me, but if they were always incorrect, that's a strong indicator that they are probably unused.

Conclusion: Fixing these types :+1:

David: Curious how they got wrong though.

Seems to be a copy-paste error

Conclusion: Ask to split the PR and do an FCP for the type changes.

Amanieu to reply.

### (waiting on team) rust.tf/100455 *Implement RefUnwindSafe for Backtrace*

Amanieu: Dislike RefUnwindSafe.

Mara: Yes, we should remove it or something.

David: This PR seems fine, just FCP?

(some discussion on whether Backtrace is ref unwind safe. -> yes)

Amanieu: It's annoying that we have to do this for all types.

Mara: We already have types that implement (Ref)UnwindSafe that are not.

FCP proposed.

### (waiting on team) rust.tf/107587 *Mark \`std\` integral modules as deprecated (\`std::u32\`, \`std::i16\`, etc.)*

Mara: Last week we steered towards a clippy lint. Someone already implemented a first version of that.

We can snooze this and check back in a few months or so.

### (new change proposal) rust.tf/libs238 *ACP: \`NonNanFNN\` and \`FiniteFNN\` float wrappers*

Discussed recently. Resulted in more discussion on the thread, ongoing. Mara to continue the discussion. No team response required now.

### (new change proposal) rust.tf/libs241 *Make \`Box\` comparisons independent of allocator choice*

David: We did the same for Vec recently.

Mara: This doesn't affect stable

David: Is there ever a situation where you'd also want to compare the allocator itself instead of just the value in a Box?

Mara: No, don't think so. Same as comparing capacity for Vec.

David: Doesn't need an FCP, so we can accept the ACP and directly accept the PR.

The 8472: We should mention it on the allocator tracking issue, since it changes that feature.

Mara left a comment on the ACP.

Josh to review the PR.

### (new change proposal) rust.tf/libs242 *proc\_macro: Implementation of Extend (parameterized over Group, Ident, Punct, and Literal) for TokenStream*

Already accepted. Should've been closed.

### (new change proposal) rust.tf/libs244 *add wrapping\_offset\_from*

Mara: Tangent: What's up with the new ACP policy?
Amanieu: Oh, will work on that and merge it.

Ths 8472: This still requires the pointers to be from the same allocation?

David: It's an unsafe function, unlike the other wrapping functions.

Mara: When would you call this function instead of just offset_from?

Amanieu: wrapping_offset_from doesn't require them to be in bounds, although it still requires them to be from the same allocation.

The 8472: It could be safe, by casting both pointers to usize and then subtracting. Why is that not used?

Josh: Pointer provenance?

The 8472 + David: This returns a usize, no pointer provenance involved.

Mara: Not convinced we should have an unsafe wrapping function, since all others are safe.

Amanieu: Requiring that both pointers are from the same allocation is necessary for const eval.

Mara: Would it be fine if it was safe, but const eval can still result in an error if the pointers are not from the same allocation?

Amanieu: There is also the alignment requirement.

Mara: Just round down?

Amanieu: That doesn't allow for the efficient llvm intrinsic.

David: Use case for ZST slices is mentioned: In an iterator with a start+end pointer pair, pretend the ZST elements are 1 byte and use a out-of-bounds pointer.

The 8472: Alternative is to use a union of pointer and usize, and use the usize for ZST types. Does const eval support unions?

[..] Or use pointer::invalid() to create that.

David: Ralf says you cannot iterate like that over a ZST slice today in const.

The 8472 + Mara: Seems like you can.

David: Question for Ralf then?

Main question seems basically "what's the use case and does that have a different solution?".

Mara to reply.

Let's talk more about it next week.

### (new change proposal) rust.tf/libs245 *Remove \`MaybeUninit::slice\_as\_(mut\_)ptr\` and optionally add \`\*const/\*mut MaybeUninit\<T\> \-\> \*const/\*mut T\` type safe conversions*

Mara: Removing :+1:

Amanieu: Removing seems fine.

Mara: The newly proposed methods: those are methods on pointers rather than on MaybeUninit, but perhaps that's just a rustdoc issue.

Mara: How would methods on pointers scale if we add this for other types in the future too? (UnsafeCell, Atomic, .. etc?)

Amanieu: The general problem seems to be casting pointers between repr(transparent) wrappers.

Amanieu: This is the projection stuff we talked about before.

Mara: Yup.

Amanieu: You can also just do .cast(). That'd just work.

David: But then you must get the type correct, though.

David: I don't see a strong motivation for adding methods on the pointer type. Maybe on the MaybeUninit type, but probably unnecessary. Additional type safety might not be worth it.

The 8472: The second part in the ACP is optional. So let's not accept the second part.

David: What about the first part? (Removing a method.)

Mara: Amanieu and I +1'd that.

Josh: Seems fine to me too.

The 8472: About part 2: Can we do it as `impl MaybeUninit { fn ..(self: *const Self) .. }`? Can arbitrary self types do that?

Mara: You might want to go through two wrappers or two slices, which is not covered by these methods. Maybe .cast() is enough.

{more discussion on alternative methods}

Mara: Let's just accept part 1 and not part 2.

Mara left a comment.

### (stalled change proposal) rust.tf/libs116 *Lossy UTF8 conversion of owned types (\`Vec::\<u8\>::into\_utf8\_lossy\`).*

Mara: Seems like this should go on String rather than Vec, but unfortunately String::from_utf8_lossy is already taken by the slice input version.

The 8472: See my comment about an alternative: It could be a method on FromUtf8Error, since FromUtf8Error still owns the Vec and knows where the first failure was.

Josh: Significantly more verbose though.

Mara: Wouldn't mind having both.

Amanieu: Original proposal seems fine.

Josh: Zero objection to also add it to FromUtf8Error. Not sure how often it'd be used though.

Mara: We'd use it in the implementation of Vec::into_utf8_lossy :)

David: Naming: Should it be "utf8" or "string"?

Mara: Agree that's an issue.

The 8472: Then maybe it should be on String, using "from utf8" naming?

Josh: Having it on Vec might be more convnient.

Amanieu: Could we *change* the existing from_utf8_lossy to take a Into Cow instead of a &[u8]?

Mara: That might be too generic; accept too much.

The 8472: Could be a custom trait rather than Into.

David: How about: String::from_utf8_lossy_owned? Currently you'd already write 'owned' as part of 'String::from_utf8_lossy().into_owned()'.

Mara: +1

Amanieu + Josh: from_owned_utf8_lossy?

David: Prefer `_owned` at the end. My justification is... weak. ^^'

David: I'd call this because i care that the output is owned, more than that the input is owned.

The 8472: Also nice for autocompletion, that from_utf8_lossy will also suggest the \_owned version.

~~David~~ Josh to comment

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

Skipped; too large to discuss right now.

### (stalled change proposal) rust.tf/libs119 *ACP: Add a constant for the golden ratio (phi) to the floating point types*

All of these exist in C++.

Seems fine.

Josh to comment.

### (stalled change proposal) rust.tf/libs115 *ACP: Range::cmp\_scalar; comparison (less/equal/greater) to a primitive of the Range*

`binary_search_by` example seemed compelling

There's more to discuss than we can fit in this meeting, but do we want something like this at all?

Mara: Yes

Josh: Yes

.. *silence*

### (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)_