# Libs-API Meeting 2023-10-03
###### tags: `Libs Meetings` `Minutes`
**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, Mara, The 8472, Chris Denton, Urgau
## Agenda
- Triage
- Anything else?
## Triage
### FCPs
29 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/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/111922 *feat: implement \`DoubleEndedSearcher\` for \`CharArray\[Ref\]Searcher\`* - (4 checkboxes left)
- merge rust.tf/80552 *Tracking Issue for the GroupBy and GroupByMut iterators* - (3 checkboxes left)
- merge rust.tf/114986 *FCP process: Require 2/3 majority for FCP* - (4 checkboxes left)
- merge rust.tf/115333 *Guarantee representation of None in NPO* - (4 checkboxes left)
- merge rust.tf/98245 *Tracking Issue for \`feature(file\_set\_times)\`: \`FileTimes\` and \`File::set\_times\`* - (3 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (1 checkboxes left)
- merge rust.tf/115108 *Fix exit status / wait status on non\-Unix cfg(unix) platforms* - (3 checkboxes left)
- merge rust.tf/76118 *Tracking Issue for \`array\_methods\`* - (4 checkboxes left)
- merge rust.tf/110604 *Implement \`BufRead\` for \`VecDeque\<u8\>\`* - (4 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/116172 *Broaden the consequences of recursive TLS initialization* - (3 checkboxes left)
- merge rust.tf/113747 *impl Not, Bit{And,Or}{,Assign} for IP addresses* - (3 checkboxes left)
- merge rust.tf/69821 *Tracking Issue for const \`mem::discriminant\`* - (7 checkboxes left)
- merge rust.tf/115955 *Stabilize \`{IpAddr, Ipv6Addr}::to\_canonical\`* - (3 checkboxes left)
- merge rust.tf/113833 *\`std::error::Error\` \-\> Trait Implementations: lifetimes consistency improvement* - (4 checkboxes left)
- merge rust.tf/110729 *Implement FusedIterator for DecodeUtf16 when the inner iterator does* - (3 checkboxes left)
- merge rust.tf/116218 *Stabilize \`const\_maybe\_uninit\_zeroed\` and \`const\_mem\_zeroed\`* - (7 checkboxes left)
- merge rust.tf/115719 *Stabilize \`atomic\_from\_ptr\`* - (3 checkboxes left)
- merge rust.tf/116233 *Stabilize \`const\_maybe\_uninit\_assume\_init\_read\`* - (3 checkboxes left)
- close rust.tf/115157 *Make \`RefMut\` \`Sync\`* - (3 checkboxes left)
- merge rust.tf/115974 *Split core's PanicInfo and std's PanicInfo* - (3 checkboxes left)
[BurntSushi (23)](https://rfcbot.rs/fcp/BurntSushi), [m-ou-se (17)](https://rfcbot.rs/fcp/m-ou-se), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [yaahc (3)](https://rfcbot.rs/fcp/yaahc), [joshtriplett (19)](https://rfcbot.rs/fcp/joshtriplett), [Amanieu (21)](https://rfcbot.rs/fcp/Amanieu), [pnkfelix (4)](https://rfcbot.rs/fcp/pnkfelix), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [Mark-Simulacrum (1)](https://rfcbot.rs/fcp/Mark-Simulacrum), [nikomatsakis (3)](https://rfcbot.rs/fcp/nikomatsakis), [pietroalbini (1)](https://rfcbot.rs/fcp/pietroalbini), [tmandry (2)](https://rfcbot.rs/fcp/tmandry)
### (nominated) rust.tf/53485 *Tracking issue for RFC 2351, "Add \`is\_sorted\` to the standard library"*
Discussed at end of last meeting, but didn't finish discussion.
Two open questions:
- Return type of is_sorted_by closure. bool vs `Option<Ordering>`.
- Should there be a function that returns the index until which the list is sorted.
Also brought up last week (by David): is_sorted_by_key is just map().is_sorted(). do we still need it?
Mara: I argued that we should have the by_key version for discoverability.
The 8472: There is no .map() on slice, but there is on Iterator. So we could remove Iterator::is_sorted_by_key, but leave it on slice.
{Discussion on what that means for references}
conclusion: map+is_sorted is truly equivalent.
The 8472: If you're already dealing with an iterator, you're already combining operations anyway, so expecting map+is_sorted is fine.
Mara: I think the more interesting questeion is the bool vs Ordering question. Returning bool makes more sense to me, but then the function can be used for many more things than just checking if something is sorted.
The 8472: Basically .windows()?
Mara: .windows(2).all(), basically.
The 8472: We discussed this in another context, I think.
Amanieu: The binary_search function takes a closure returning Ordering
Mara: That one makes a trinary decision though. (Continue left, continue right, or stop). is_sorted_by just makes a binary decision.
{discussion about NaN/non-Ord}
Mara: if we define is_sorted as is_sorted_by(|a, b| a <= b), it seems clear? NaN item results in false. having a non-sortable item means the list is not sorted.
Amanieu: should is_sorted be fallible?
Mara: Don't think so. <= is also not fallible. Just returns false for NaN.
Mara: is_sorted is basically: a <= b <= c <= d ... <= x
Amanieu: is_sorted_by closure could return Ordering. not clear what bool means?
Mara: same meaning as the return value of is_sorted_by: true is sorted, false is not.
Then you can also pick `a < b` instead of `a <= b` for 'strictly increasing'
Amanieu: Convinced. bool sounds good.
Amanieu: next question: return position?
Mara: Just like this is .windows(2).all(), that function would be .windows(2).position. (We don't have windows/array_windows on Iterator yet though.)
Amanieu: is_sorted_* is the common case. Fine to just write a loop.
The 8472: We have map_windows (on nightly) that covers this.
Mara: David was also in favor of bool.
Conclusion: bool: yes. extra method for position: no.
The 8472: is is_sorted_by reasonable when it isn't necessariliy about sorting though?
Amanieu: should we have a is_sorted() free function that works on both arrays/slicse and Iterator?
Amanieu: I think no.
Mara: No, not what we do in any other place.
Mara to reply.
### (nominated) rust.tf/91345 *Tracking Issue for \`result\_option\_inspect\`*
Last meeting the last comment was from someone who realized they don't want this anymore, because they wanted .tap() instead.
Lot more comment activity since then though.
Discussion ongoing. Let's discuss later.
### (nominated) rust.tf/96283 *Tracking Issue for pointer\_bytes\_offsets*
Already in FCP
### (nominated) rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`*
Mara: I agree with what niko is saying, roughly saying that there should've been different Ord traits for 'semantic ordering' and 'just some ordering'.
Amanieu: If you use a BTreeMap, ordering usually matters.
Mara: I often use a BTreeMap not to keep things sorted, but just as an alternative ot HashMap, where any order works.
Amanieu: i prefer making Discriminant Ord.
Mara: Agree
The 8472: I'd prefer this going through some method with something like 'unstable' in the name.
Amanieu: I recently presented something about 'stable ABI' for Rust. In that proposal, reordering enum variants would be an ABI change.
The 8472: Sure, but not an API change.
Amanieu: If you're going to make it a method with a scary name, then we might as well return an integer/index. usize or u32 would always be enough.
Mara: This issue all comes down to a question on the definition of Ord. We don't have good and consistent deifnitions of Ord and Eq etc.
Amanieu: Let's defer until david is back.
### (nominated) rust.tf/115333 *Guarantee representation of None in NPO*
Already in FCP. doesn't need to be nominated.
### (nominated) rust.tf/115652 *Add buffering to stdout*
Summary from previous discussion: https://github.com/rust-lang/rust/pull/78515#issuecomment-1168362639
We first need to settle the existing discussions.
Amanieu: We should do this, by making block buffering the default we're on par with C.
Mara: I have software that would break then.
The 8472: Then you're relying on implementation details.
Mara: Sure. But still, I rather have people opt-in to higher performance than have people opt-out of confusing behaviour. I don't want stack overflow filled with questions about why their rust program suddenly gives no output.
The 8472: Different languages do different things. There's not a single best practice.
Mara: I'll reply saying that this needs resolving before we can review this PR.
The 8472: We can first accept a PR that exposes this as an opt-in discussion without changing the default yet. Then we can make a step forward.
:+1:
### (nominated) rust.tf/115974 *Split core's PanicInfo and std's PanicInfo*
Amanieu: My issue is that the same path in core and std now resolve to different types. Problem if we want to unify core and std.
Mara: If you use std, you can't define #[panic_handler], so you don't need core's PanicInfo.
The 8472: But in the future you might be able to disable just the std panic handler.
Mara: We could make #[panic_handler] accept multiple signatures, but then we'd still need std PanicHandler in core, where we don't have String etc.
Amanieu: I'd like to spend some time redesigning panic mechanism from scratch to see where I end up.
Mara: sgtm, curious to hear what you end up with. :)
### (waiting on team) rust.tf/114149 *\`read\_dir\` has unexpected behavior for \`""\`*
Stuck.
### (waiting on team) rust.tf/115386 *PartialEq: handle longer transitive chains*
Discussed last week. David replied.
Ralf didn't like the resolution ('not worth documeting') though.
Mara: Kinda similar to what we discussed before, how Ord/Eq etc. are more 'vibes based' without a clear mathematical definition. Solution would be cool, if possible.
Amanieu: I need to read through this thing.
The 8472: Documenting how to do things right is good.
Mara: Yes, but I'm also not sure if adding this documentation would actually change anything in practice.
The 8472: The issues on the interals forum are very abstract. More concrete examples would help.
Mara: Maybe this just needs to be documented in a more accessible way.
Mara: We already have quite a bit of trouble understanding the exact implications of these rules.
Amanieu: Yeah, the average user has no chance.
### (ACP) rust.tf/libs187 *\`Try\` for \`()\`*
Amanieu: Against more Try impls, because it messes with type inferrence.
Amanieu: We already regret Try for Poll
Mara: Yeah, but this one is consistent, unlike Poll.
Mara: There are still several possible designs for Try floating around. We can't really add these impls if we don't know where Try is going..
The 8472: Ask scott, who originally designed Try?
Amanieu: Looks like they want to use this in rustc.
https://github.com/rust-lang/rust/pull/108598
Mara: Looks like they want to avoid having to put `-> ControlFlow<!>` everywhere.
Amanieu: MCP: https://github.com/rust-lang/compiler-team/issues/597
Amanieu: That's a good motivation. Instead of a flag, they want to properly use ControlFlow.
Mara: The downside is that `()??????` will work.
Mara: `println!("asdf")?;` would then work. even though it doesn't do anything.
Looking at:
```rust
fn walk_foo<V: Visitor>(v: &V, foo: &Foo) -> V::ResultTy {
// walk foo using `?` when needed
V::ResultTy::from_output(())
}
```
Mara: That would work fine when using `ControlFlow<!>` instead of `()`, right?
Amanieu: Yes. But they don't want to change all those visitors that don't need early return. Not having to add Continue(()) everywhere.
Mara: Same problem as changing to Result, adding Ok(()) everywhere. Not great, but just how Rust works today.
Mara: Sounds like they want `fn ..() try { .. }`.
Amanieu: the 'ok wrapping'?
Mara: Exactly. ('continue wrapping' in this case)
Amanieu: I think this (the ACP) is the wrong way to solve this.
Mara: accepting `println!("")????;` is very bad.
Amanieu: Maybe this can be solved with a custom trait? Solving it without affecting all code everywhere.
Mara: The underlying issue they run into is far bigger than what this ACP tries to address. 'solving' this in the library with this trait impl is not the solution. Having to deal with fallible+infallible variants of everything is a issue that pops up everywhere in Rust. I'd love to see it solved, but this is not a solution.
Mara to reply.
### (new change proposal) rust.tf/libs266 *Add a \`thread::park\_until\` method*
Mara: sgtm
Amanieu: Seems fine.
The 8472: Same issue as with sleep: which clock to use.
The 8472: Also, you'd still need to call Instant::now to get a time relative to it.
Mara: You often use this function in a loop, where you set a deadline for the entire loop.
Mara: Most OS'es only understand the real time clock and standard monotonic clock in their 'futex wait' APIs. We wouldn't be able to change Instant::now to use another monotonic clock (e.g. with/without suspended time).
Amanieu: Adding park_until seems fine, for just Instant.
Mara: sgtm. But accepting this means we permanently attach Instant to the standard MONOTONIC clock. (Or at least the clock used by futex wait or similar OS API.) (Which I think is fine.)
The 8472: We need to check if today we use that on all platforms.
Mara: So the conclusion seems: yes, ACP seems fine, but we still need to check if Instant is always the right clock.
The 8472: So we just close all the BOOTTIME issues? Some people will be unhappy.
Mara: `Instant` will use just one clock, people who want the other will be unhappy. So if we want to satisfy everyone, we need multiple types, or a generic one. That's something that can start in the ecosystem.
In C++, there is also only the real time clock and the monotonic clock.
Amanieu to reply.
### (new change proposal) rust.tf/libs267 *ACP: Move \`std::collections::hash\_map::{RandomState, DefaultHasher}\` to \`std::hash\`*
Amanieu: Seems fine
Mara: +1
Mara: Can we do this unstably first?
Amanieu: We can do that by first unstably reexporting the new paths without moving the stable definitions.
Amanieu to reply.
### (new change proposal) rust.tf/libs268 *Implement \`into\_chars\` for \`String\`*
Amanieu: you can use iter from_fn with a closure that move-captures the string.
That's listed as an alternative. Pretty verbose.
The 8472: We have owning iterators everywhere.
Mara: I think the request is fair. It's just that I wish this was solved by the language, so we don't have to duplicate all these things.
Amanieu: We can accept and defer until stabilization.
Mara: uh, sure.
Mara: I'll also discuss this use case with Niko.
### (new change proposal) rust.tf/libs269 *Add \`try\_into\_boxed\` (and potentially \`into\_boxed\_inner\`) for \`Rc\<T\>\`/\`Arc\<T\>\` where \`T: ?Sized\`*
### (new change proposal) rust.tf/libs271 *Unix Domain Sockets on Windows*
### (stalled change proposal) rust.tf/libs152 *Feature item\_find\_many*
Seems too complicated. Feels like a simpler primitive is missing to enable these use cases.
### (stalled change proposal) rust.tf/libs156 *&mut \[MaybeUninit\<T\>\]: Fill with value or with closure.*
### (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)_
Sign in with Wallet
Connect another wallet