# Libs-API Meeting 2024-03-05

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/rfc3550 *RFC: New range types for Edition 2024* - (5 checkboxes left)

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 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/98934 *Add \`Option::take\_if\`* - (3 checkboxes left)
- merge rust.tf/99969 *alloc: implement FromIterator for Box\<str\>* - (3 checkboxes left)
- merge rust.tf/102012 *Tracking Issue for \`const\_waker\`* - (3 checkboxes left)
- merge rust.tf/106943 *Implement DoubleEnded and ExactSize for Take\<Repeat\> and Take\<RepeatWith\>* - (3 checkboxes left)
- merge rust.tf/120257 *Tracking Issue for generic \`NonZero\`* - (2 checkboxes left)
- merge rust.tf/107462 *Implement \`FromIterator\` for \`(impl Default + Extend, impl Default + Extend)\`* - (2 checkboxes left)
- merge rust.tf/113744 *Tracking Issue for \`IpvNAddr::{BITS, to\_bits, from\_bits}\` (\`ip\_bits\`)* - (3 checkboxes left)
- merge rust.tf/99262 *Tracking Issue for \`io\_error\_downcast\`* - (3 checkboxes left)
- merge rust.tf/62726 *Tracking issue for io\_slice\_advance* - (3 checkboxes left)
- merge rust.tf/109402 *Implement owned ops for \`HashSet\` and \`BTreeSet\`* - (3 checkboxes left)
- merge rust.tf/116113 * Generalize \`{Rc,Arc}::make\_mut()\` to unsized types.* - (4 checkboxes left)
- merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (2 checkboxes left)
- merge rust.tf/117468 *Stabilize Wasm relaxed SIMD* - (4 checkboxes left)
- merge rust.tf/101196 *Tracking Issue for \`Ready::into\_inner()\`* - (1 checkboxes left)
- merge rust.tf/119131 *Tracking Issue for \`hint::assert\_unchecked\`* - (2 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (3 checkboxes left)

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

### (nominated) rust.tf/121588 *strict provenance: rename addr → bare\_addr*

Mara: If we see poitners as just `(addr, provenance)`, then what's the problem with just leaving this as .addr()?

The 8472: It pairs up with ptr::without_provenance

Mara: the addr is only part of what the pointer is, so i don't think .addr() on the pointer is unclear.

Amanieu: I think .addr() is not clear enough

Mara: I don't see how "bare addr" makes it clearer.

Chris: we have `addr_of!`, which produces something that *does* have provenance

Mara: That's a pointer, not a usize. A usize by definition does not have any provenance.

The 8472: "bare" is a short-hand for "without provenance"

Josh: I don't think "bare" is a clear enough of a hint.

The 8472: The docs should explain what bare means.

David: I agree the most with Mara. Analogy with !Display for Path, intentional stumbling block as a learning moment. For provenance we already have that, in the conversion from integer to pointers. Adding another one doesn't provide teaching value.

The 8472: The problem is that you don't have to use the method, you can also do it with `as`.

Josh: More reason to not having `as` in the future.

Mara: With `as` you can convert in both directions. This should be named for a world where all conversions happen with the methods.

Mara: Also I don't think it makes sense to say that "bare" means "without provenance". usize is by definition without provenance. The difference is only whether it has been exposed or not, not whether it carries provenance or not.

David: Agree with Mara and Josh

Amanieu: don't have much opinion on this five character change (:

The 8472: Ralf writes that replacing `as` with `addr()` would be wrong. `as` does expose.

Amanieu: Agree that `addr` is too short for something that isn't a replacement for `as`.

Mara: Sounds like we do not have consensus. I'll leave my thoughts on the PR, but seems like we don't have a clear opinion as a team right now.

The 8472: The [zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Next.20steps.20for.20strict.20provenance.20stabilization/near/423262731) has more opinions.

David: I'd like to know what the goal of the rename is. Who is it for?

- intentional stumbling block for people who don't know about provenance to learn about provenance
- periodic reminder to people who already know about provenance that on this particular line of code, they need to have it in mind

### (nominated) rust.tf/121920 *downgrade ptr.is\_aligned\_to crate\-private* and rust.tf/121948 *stabilize ptr.is\_aligned, move ptr.is\_aligned\_to to a new feature gate*

Mutually exclusive PRs. Either remove is_aligned_to or split it off to a separate unstable feature.

The 8482: You can't use is_aligned with a dynamic value. E.g. if you have a Layout with an alignment value.

Josh: Let's FCP is_aligned and leave is_aligned_to for later. So, FCP the second PR.

Mara: +1

Mara proposed FCP.

### (waiting on team) rust.tf/119550 *Rename \`AsyncIterator\` back to \`Stream\`, introduce an AFIT\-based \`AsyncIterator\` trait*

[_"I'm converting this to a draft PR until we have consensus within WG Async how we want to proceed"_](https://github.com/rust-lang/rust/pull/119550#issuecomment-1889345647)

Still draft.

### (new change proposal) rust.tf/libs342 *Add raw\-pointer\-to\-reference conversion methods*

Josh: Automatically in favour of anything that gives a name to an `_ as _`.

Amanieu: unchecked is maybe not a good name, it only doesn't checks non-null

Mara: +1, it's not like we have a safe checked version. the checked version is still unsafe.

Mara: So, today, you'd do `.as_ref().unwrap_unchecked()`.

The 8472: `pointer::split_at_mut` and `split_at_mut_unchecked` are also both unsafe.

Amanieu: Since we don't have better ideas for the name, let's go for it as unstable.

Mara: +1

Josh: +1

Mara replied and accepted the ACP.

### (new change proposal) rust.tf/libs344 *ACP: Add \`std::string::String::replace\_and\_count\` and/or \`replace\_with\`*

Mara: replace_and_count seems super specific. How often do you want to count but not also know the positions for example?

Amanieu: I think there should be a bar at which we should point people to the regex crate?

Josh: If we think replace_and_count shouldn't be served in std, then this ACP seems like it doesn't have sufficient motivation for adding `replace_with`.

{discussion on the lifetime on the &str returned by the closure}

Mara: How about giving an FnOnce(&str) to the closure to replace the string

David: Yeah that's better.

Mara: replace_with seems super useful if it gets the to-be-replaced &str. it can do all kind of conversions.

Josh: Yeah, like to_lower or something, but more complicated

Mara: But then it should probably also return a ControlFlow so it can break early. Might get a bit too complicated.

The 8472: The generalization game can be pushed arbitrarily far.

Josh: replace_with seems useful, but let's not design in this meeting.

Josh: Sounds like the conclusion is replace_and_count is too specific, but we might want replace_with, to be designed.

Mara: I can reply saying that option 1 and 3 won't fly, but that option 2 _might_ fly, together with some thoughts on the API.

Josh: And ask for use cases.

Amanieu: `regex` has this. So probably fine.

Mara to reply.

### (new change proposal) rust.tf/libs346 *ACP: \`impl {Div,Rem}Assign\<NonZeroX\> for X\`*

Seems fine. :+1:

ACP accepted. FCP started.

### (new change proposal) rust.tf/libs347 *Context reactor hook*

Pinged async-wg.

### (new change proposal) rust.tf/libs348 *std::os::unix::env::{argc, argv}*

Mara: argc+argv is stored in std, so exposing them makes sense to me.

Amanieu: the motivation is performance, which i don't think makes sense.

Mara: FFI is also a motivation.

Mara: I think it should be a single argc_argv() function, and the pointer types should be mutable.

Chris: If someone is muting the arguments, that is very unsafe.

The 8472: We don't give you any way to make it safe, because we don't provide any locking for the memory that stores argv.

Josh: I think it's fine that they're unsafe.

The 8472: It's impossible to wrap it in an abstraction that makes it safe.

Mara: There are safe ways to use it. Exactly the same ways as in C. E.g. at the start of main()

The 8472: If you use tokio_main you immediately have some threads running.

Josh: Same as with env vars. Often unsafe. But it's possible to use safe.

The 8472: Do we need to propagate the mistake from C?

Josh: Too late.

The 8472: If we expose this, we should provide a lock mechanism.

Amanieu: If we want to expose a function for setting the program name, that should be a proper method.

Josh: We could keep it `*const`, and have a separate function for setting the name.

Mara: Once we expose the pointer, we cannot add a lock later and expect readers to lock the lock.

Josh: With or without a lock, it'll be equally unsafe.

The 8472: They should use libc.

Mara: It's not a libc thing, it's a C thing. argv+argc are arguments to main that we don't pass on to Rust main but instead store. Since we took away their argv+argc, we should provide it to our users in another way.

David: Another solution could be to let the user provide their own entry point that receives argc+argv.

Mara: Would love a language feature that makes that easier.

Amanieu: no_main and no_mangle is stable, but that doesn't let you call into the Rust runtime.

The 8472: There is no difference between `*mut` and `*const` when it doesn't come from a reference.

Josh: `*const` might make people think it is const.

The 8472: I don't think this API is good design.

Mara: It's a very low level thing. I think it's important that Rust exposes low level things.

Amanieu: Use cases unclear.

Josh: I like the argument that this is the form we got the data in and don't expose them unmangled.

Mara: If i just want to call a syscall (e.g. exec) with the exact argc+argv, then i want to pass just those instead of reconstructing it.

Amanieu: The Rust runtime takes ownership of this data. Getting it out should be done through std::env::args

Mara: We have as_ptr on Box and other things, why not for the arguments?

The 8472: Because Box has clear ownership, and arguments don't.

Josh: Seems like a pattern of global data from a C world. Do we try to stay away from that or do we give people the thing we already have?

The 8472: If there was a dire need for access, it'd be a different story. But this can mostly be approximated today. The only thing we don't cover is renaming the current process.

Mara: Reconstructing an argv-like array (e.g. for execve) is more error prone, more unsafe, than just using the existing argv.

Mara: In C i can just write a program that takes argc+argv and direclty calls execve. In Rust that same program would be much bigger, doing allocations, etc.

Mara: We took data away from the user, we should give it back (unsafely).

The 8472: We take a lot of pointers away from the user.

Mara: Not without giving it back with some unsafe method.

Josh: No consensus then?

Amanieu: Still in favour of reject.

Mara: Still in favour of accept.

Josh: Would people be opposed to a lang feature for providing your own `main` wrapper?

Amanieu: That's fine.

The 8472: If we have clear ownership transfer, then yes.

Mara to write a comment to ask the author what they think about such a lang feature, if that would also satifsy them.

### (stalled change proposal) rust.tf/libs201 *ACP: Provide \`TryFrom\<&\[T\]\>\` implementation for \`&\[\[T; N\]\]\`*

Open question is what to do with the N==0 case:

The 8472: Doesn't need to panic for N==0, you can just return an Err.

Josh: Compiling and returning an Err seems completely valid.

Mara: Yeah seems fine.

About the concept in general:

Josh: I agree this functionality should exist, but not sure whether as method or TryFrom

Mara: Leaning towards a method. We don't have From &T to &[T; 1] for example.

Mara: If we accept this, should we have From/Into for all kind of flattened/regrouped arrays/tuples?

Mara: I don't think we should treat `[` and `]` as "ignorable noise", allowing you to remove/add them with just .into().

Josh: To be clear, I'm in favour of adding this as a method.

The 8472: from &[] to &[;N] already exists.

Mara: That doesn't remove or add `[` and `]`. It just erases or puts back the length into a slice.

Josh: Name of the method?

The 8472: `as_chunks_exact`

Mara: +1

Amanieu: Just say that this shouldn't be a TryFrom, but that this should be a method?

Mara+Josh: +1

Josh to reply.

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

Mara: Not sure how to discuss right now without knowing all the context. Need some time to read.

### (stalled change proposal) rust.tf/libs196 *ACP: Implement FromIterator for Box\<str\>*

FCP poposed a while ago. Checked another box. FCP started now. ACP accepted+closed.

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

Discussed a few times before. Conclusion was "this is not what you want", with an example showing how you want to use parition_point.

### (stalled change proposal) rust.tf/libs166 *Add \`Option::transpose\_fn\` methods*

### https://github.com/rust-lang/libs-team/issues/340 *Add HashMapEntry and BTreeMapEntry aliases to std::collections*

You can already do this yourself with `use ... as`, and in the future we could use "inherent associated types" to allow `HashMap::Entry`.