# Libs-API Meeting 2023-12-12

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

17 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/117905 *revert stabilization of const\_intrinsic\_copy* - (3 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/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)

[joshtriplett (10)](https://rfcbot.rs/fcp/joshtriplett), [BurntSushi (7)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [m-ou-se (9)](https://rfcbot.rs/fcp/m-ou-se), [Amanieu (10)](https://rfcbot.rs/fcp/Amanieu)

### (nominated) rust.tf/94069 *Restrict \`Allocator\` impl to \`&'static A\`*

Amanieu: If you have a `Pin<Box<T, A>>` and leak it, then the allocation has to be leaked (which means the allocator has to be leaked), because a `Pin` guarantees it stays valid until drop, which is forever if you leak it.

Mara: Should `Box::leak` require `A: 'static`?

Amanieu: It's not about `leak`, it's about `mem::forget`.

Mara: Can you give a example where it goes wrong?

Amanieu:

let stackalloc = StackAlloc([0; 1024]);
// impl Allocator for &'_ A where A: Allocator
let b: Pin<Box<T, &'_, StackAlloc>> = Box::pin_in(T, &stackalloc);
f(&b); // assumes pinned
mem::forget(b); // memory must stay unused forever, because of pin
drop(stackalloc);
// if T has an intrusive linked list or w/e, things go kaboom here.

Mara: Couldn't we instead restrict Box::pin_* ?

Amanieu: Today this doesn't compile because `Box::pin_in` requires `A: 'static`.

Amanieu: pin_in already requires `A: 'static`. https://github.com/rust-lang/rust/pull/90822 relaxes that.
That was abandoned in favor of https://github.com/rust-lang/rust/pull/94114 which was closed because of inactivity.

Amanieu:

> Memory blocks returned from an allocator that are currently allocated must point to valid memory and retain their validity while they are currently allocated and at least one of the instance and all of its clones has not been dropped.

Mara: You're proposing *not* merging the PR we're discussing, and instead fixing docs?

Amanieu: Yes. Current docs don't allow stack allocators. We should fix that.

Amanieu: I'll send a PR to update the definition, and close this one.

### (nominated) rust.tf/108443 *Tracking Issue for ip\_in\_core*

Mara: Would this be the first time we stablize non-essential (not related to lang items, etc.) stuff into core?

Josh: FFI types, for example.

Josh: In general, we put std things in core if they don't depend on the os.

Mara: Fair. If it is already in std, we should move it to core if it doesn't depend on OS/alloc/etc.

Amanieu: +1. The bar for std is high, the bar to move something already in std to core should be low.

David: Another example: `core::time::Duration`.

Mara: Should AddrParseError be multiple types? https://doc.rust-lang.org/1.73.0/src/core/net/parser.rs.html#488

Amanieu: Already stable in std.

Josh kicked off FCP.

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

David: Still working on this with Ralf.

David: Rule would be limited to chains from most local to most remote in dependency tree.

Mara: Cool if we can find a rule that works/holds, but is this practical or useful to anyone?

Josh: Seems not possible to really use this for any reasoning.

Mara: Why are we providing a transitivity rule at all? Is it a guideline to implementors only? Or ..?

David: Ralf would like to have a rule that reflects reality. Useful even if we don't document it.

David: We should invite Ralf to our meeting to finish this discussion.

Mara: If we were to simply remove the 'transitivity' property entirely. Would that practically change anything for anyone?

Josh: It's just a guideline for implementing it. "Should" not "must". Making it more precise makes it less accessible. I don't think we should remove it entirely, though.

Mara: Agreed. If the only use is guidelines... the (proposed) rules are hard to understand, don't work well as a guideline.

The 8472: We should question how many people actually rely on complex (PartialEq) relationships.

David: Agreed that a complicated rule doesn't help our users, but changing "must" to "should" isn't really a solution.

Mara: Yes, we should write it in terms of 'expectations users (of your impl) might have', and note it's a safe trait that anyone can implement however they feel is right.

David: In our first discussion on this, we already concluded that we shouldn't pin down exact rules.

Mara: We should find out what properties people actually rely on. Symmetry seems obvious, but do people actually rely on the transitive property (in generic functions or something)?

The 8472: {example with Cow}

Mara: That could be covered by a rule/guideline about wrappers/boxes behaving transparently, right?

Mara to post a comment.

### (nominated) rust.tf/116888 *Add discussion that concurrent access to the environment is unsafe*

Amanieu: Can we make set_env unsafe in the new edition?

Mara: Probably!

The 8472: https://github.com/rust-lang/rust/issues/94978

Josh: `#[deprecated_safe]` was designed for this exactly. So we should use that.

Mara: Yes, and then the docs can explain why it is "unsafe".

Was tried before: https://github.com/rust-lang/rust/pull/95942
but author disappeared. never got merged.

Amanieu: Safety precondition: only use this in single threaded programs.

Josh: Too restrictive. Safe if only one thread is touching the environment. Safe if all threads are Rust, etc.

Amanieu: A lot of std reads the env behind your back.

The 8472: Safe, because we lock the env.

Mara: Do we even lock the env for dns lookup, etc.?

The 8472: We should.

Josh: We need to allow multithreaded program, e.g. if a thread pool has already started but is not doing anything.

Amanieu: We can't guarantee that nothing in std uses env vars indirectly from those other threads.

Amanieu: just don't use set_env. just don't modify the env of your own process, only for spawned processes.

Josh: Lots of (old) code needs env vars to be set (within a process). Rust needs to be able to interface with that.

Amanieu: We can say that it must be either single threaded, or you must figure out yourself (without help from us) that nothing else will touch the environment.

Josh: Sounds fine.

Mara: +1

Mara to try to make deprecated_safe an edition 2024 thing.

Amanieu to post a reply.

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

Skip.

### (waiting on team) rust.tf/118087 *Add Ref/RefMut try\_map method*

Mara: Basically an ACP with implementation.

The 8472: Doesn't have a moviation etc. though.

Amanieu: How do we feel about this new method?

Mara: We should not be adding more `try_*` until we figure out the Try trait. This just uses Result.

Josh: We can ask the author to use the Try trait and warn them we won't stabilize it until we figure out the Try trait.

The 8472: Try traits mentioned in PR description.

David: Yeah they said it's impossible to add information into the Err part.

The 8472: Something we should raise on the Try trait tracking issue.

Amanieu: With an Option, you can't put anyting in the error type..

Mara: The `Result<.., (Self, E)>` type is a bit odd.

Amanieu: Should we argue that the signature is not useful?

David: It can be done today by making the FnOnce store the error somewhere else.

Josh: Pattern where we sometimes want to conditionally consume Self.

Amanieu: Don't see how we could solve that at the language level.

Amanieu: Propose using Try trait and not return Self at all?

Mara: Would that still be useful?

The 8472: We don't know! There's no motivation in the PR.

Amanieu to send a PR for the std-dev-guide about ACPs.

Mara to reply.

### (waiting on team) rust.tf/118523 *Add ASCII whitespace trimming functions to \`&str\`*

Already on `[u8]`, this copies them to `str`.

The 8472: If we keep replicating all this on `[u8]` and str, we should work on a generalized Pattern API.

Mara: Let's add these to the same tracking issue as the `[u8]` ones.

Amanieu, Josh: +1

Josh replied.

The 8472: Not just str or [u8] but also [ascii::Char]

Mara: We're getting a lot of string types.

### (new change proposal) rust.tf/libs311 *ACP: Pattern methods for \`OsStr\` without \`OsStr\` patterns*

The 8472: Would this also soon get a trim_ascii_whitespace() etc?

Josh: This is just the Pattern methods.

Amanieu: We have too may string types. We should stop adding more string types, but adding the full API on all existing string types.

Mara: We're already in the process of adding another string type: slice of ascii::Char.

Mara: I think this should be an RFC. Easier to discuss revisions and start threads about specific methods/lines of the proposal.

Mara: We can ask for an RFC, but we should warn Ed that this will probably result in a discussion on the other string-like types as well.

Mara: Perhaps we can remove some of these methods. E.g. split_once could cover all use cases for split and splitn.

The 8472: That's just avoiding the solution of the many string types.

Mara: True, but in case we can't solve that.

Mara: Ideally, we'd have a "string trait". Not sure if possible.

Josh: You'd still need many impls.

Mara: Default impls for split and splitn (using split_once) is possible, for example.

Mara: Right now, we don't seem to know how feasible a generic solution is. We should probably explore that first before considering this..

Mara to reply.

### (new change proposal) rust.tf/libs305 *ACP: Impl From\<&T\> for &\[T\]*

The 8472: [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60std.60.20conversion.20traits.20are.20a.20mess/near/404263203) "everything should be From"

Amanieu: How much does this break type inferrence?

Mara: Suppose it didn't, then this would be fine, right?

Josh: Yeah

Amanieu: No, I find it confusing. Converting a reference feels strange.

Mara: Might be confusing if something takes a `&[T]`, then passing a `&T` through `Into` making a slice of 1 element is not immediately obvious when reading the code. Maybe not intended.

Amanieu: The power of `from_ref` is that it keeps the same lifetime. Not clear with `From`.

Josh: If we didn't already have `from_ref` and `from_mut`, we might entertain these From impls.
But we already have them, so how much value do we add by allowing spelling these as From and Into?

Mara: Ask for new motivation?

Amanieu: Would need a strong motivation. Just close this and ask to reopen if they have strong motivation for having From/Into on top of the from_ref methods.

The 8472: We don't have strong motivation for many of our From impls..

Mara: I don't feel strongly, i'd check my checkbox if we were to FCP-merge this.

Josh to reply.

### (new change proposal) rust.tf/libs308 *ACP: Introduce checked\_split\_at{,\_mut} methods*

Mara: Feeling very neutral about this. :woman-shrugging:

Mara: we have (unstable) `split_at_unchecked` but this is `checked_split_at`.

Josh: There was some discussion on this on the ACP issue.

Amanieu: We should also have this on str. Then it also checks utf-8 boundary.

The 8472: Other offset-taking methods that lack a checked version: `split_array_mut`, `select_nth_unstable`

Mara: Should it then have an error type for oob vs utf8 error? I think no, just None.

Mara: split_at is just get/Index twice. only split_at_mut is interesting. but a `mut str` is rarely interesting.

Josh: I've used split_at to not have to name the binding for the midpoint expression. But yeah, once you've named the midpoint expression, you can `s[mid..]` and `s[..mid]`.

Mara: Accept as unstable?

Amanieu: mildly positive

Josh: feeling neutral

The 8472: Would have been nice if we had only checked methods, and operators to turn them into panicking/unchecked.

Josh: We have gotten more requests for a unwrap operator. But we rejected those because unwrapping is often not the right pattern.

Mara: But we do have a get-or-panic operator (Index). So..

Josh: Yeah, might be worth evaluating. This might have convinced us in the past.

Mara: Something something Rust 3.0.

Mara to reply.

### (new change proposal) rust.tf/libs310 *Add \`array::repeat\` for making an array from a non\-\`Copy\` non\-\`const\` value*

### (new change proposal) rust.tf/libs313 *ACP: Add ASCII whitespace trimming functions to \`&str\`*

Discussed above.

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

The 8472: Not implementable on all platforms.

> I could not find any equivalent syscall on non-Linux unix systems (*BSD), and don't know how to deal with that aspect.

Josh: Is "atomic" relevant, when not replacing a file?

Mara: Can be relevant. You might not want to have incomplete files, which was probably the entitre reason for writing a file under a different name first and then renaming.

The 8472: Could symlink dest->src, then rename src->dest

Josh: If we're going to have a race anyway, we might just do create_new+rename.

Josh: We could also use hardlink + unlink as fallback on platforms that don't support RENAME_NOREPLACE
and document that users shouldn't use this method if two files existing temporarily is not acceptable.

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