# Libs-API Meeting 2026-04-28

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Nia Espera, Josh Triplett, Chris Denton, bstrie, Max Heller, Waffle, The 8472

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/106418 *Implement \`PartialOrd\` and \`Ord\` for \`Discriminant\`* - (2 checkboxes left)
- merge rust.tf/149219 *Allow shortening lifetime in CoerceUnsized for &mut* - (4 checkboxes left)
- merge rust.tf/127544 *Tracking issue for CommandExt::show\_window* - (3 checkboxes left)
- merge rust.tf/155113 *Ensure Send/Sync impl for std::process::CommandArgs* - (3 checkboxes left)
- merge rust.tf/155153 *Ensure Send/Sync is not implemented for std::env::Vars{,Os}* - (3 checkboxes left)
- merge rust.tf/152367 *Derives \`Copy\` for \`ffi::FromBytesUntilNulError\`* - (3 checkboxes left)
- merge rust.tf/116258 *Tracking Issue for explicit\-endian String::from\_utf16* - (1 checkboxes left)
- merge rust.tf/98407 *Tracking Issue for \`SyncView\`* - (0 checkboxes left)
- merge rust.tf/140808 *Implement Default for &Option* - (1 checkboxes left)
- merge rust.tf/141994 *add Iterator::contains* - (1 checkboxes left)
- merge rust.tf/76314 *Tracking Issue for atomic\_from\_mut* - (1 checkboxes left)
- merge rust.tf/151379 *Stabilize \`VecDeque::truncate\_front\`* - (3 checkboxes left)
- merge rust.tf/149926 *Do not deduplicate captured args while expanding \`format\_args!\`* - (1 checkboxes left)
- merge rust.tf/111688 *Tracking Issue for ExitCodeExt on Windows* - (3 checkboxes left)
- merge rust.tf/109737 *Tracking Issue for \`once\_cell\_try\`* - (3 checkboxes left)
- merge rust.tf/121641 *Tracking Issue for \`OnceCell/Lock::get\_mut\_or\_init\`* - (3 checkboxes left)
- merge rust.tf/134021 *Implement \`IntoIterator\` for \`\[&\[mut\]\] Box\<\[T; N\], A\>\`* - (3 checkboxes left)
- merge rust.tf/153261 *Partially stabilize \`ptr\_alignment\_type\` as \`alignment\_type\`* - (3 checkboxes left)
- merge rust.tf/142748 *Tracking Issue for producing a \`Result\<(), E\>\` from a \`bool\`* - (3 checkboxes left)
- merge rust.tf/138215 *Tracking Issue for integer formatting into a fixed\-size buffer* - (3 checkboxes left)
- merge rust.tf/153990 *Decide and document where stdarch intrinsics are allowed to diverge from asm behavior* - (4 checkboxes left)
- merge rust.tf/126769 *Tracking Issue for \`substr\_range\` and related methods* - (3 checkboxes left)
- merge rust.tf/136327 *Tracking Issue for \`unsafe\_cell\_access\`* - (4 checkboxes left)

[oli-obk (1)](https://rfcbot.rs/fcp/oli-obk), [Amanieu (3)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (14)](https://rfcbot.rs/fcp/joshtriplett), [the8472 (17)](https://rfcbot.rs/fcp/the8472), [lcnr (1)](https://rfcbot.rs/fcp/lcnr), [scottmcm (1)](https://rfcbot.rs/fcp/scottmcm), [spastorino (1)](https://rfcbot.rs/fcp/spastorino), [BurntSushi (16)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay), [BoxyUwU (1)](https://rfcbot.rs/fcp/BoxyUwU), [nikomatsakis (1)](https://rfcbot.rs/fcp/nikomatsakis)

### (nominated) rust.tf/155924 *Make \`Infallible = !\`*

Waffle: I've been running experiments to stabilize `!`. My question to the lbis team is specifically about `Infallible` and if we can make it equal to the `!`. The reason is so stdlib has proper uninhabitable type to mark unreachable code, etc. Since `Infallible` is the unreachable type I'd like to make it the same as never. Crater detected four separate breakages. How important do you think they are? What kinds of solutions we might try? Do we even want to make `INfallibale = !`?

The 8472: That was alway sthe plan. The question is if it's still feasible.

Waffle: There are four kinds of failures. With the language part of the stabilization, there's much more breakage than here. There's a problem with `anyhow!` that calls a method on an `Error`. If that error returns `!`, the type can't be inferred. There's an issue with people implementing both `Infallible` and `!`, but that's only on nightly.

The 8472: You say 20 crates there. Did you check how popular they are? When we assess blast radius, we check how popular they are, how many downloads they have.

Waffle: I haven't checked downloads. But for anyhow I've checkeed none of the failing 20 crates have reverse dependencies.

The 8472: That's a good sign.

Waffle: I can check which specific crates break and how popular they are.

The 8472: If you say they're only leaf crates, that's a good start for that issue, but there are three other issues.

Nia: A thing to consider: can we use FCW to move things forward?

Waffle: I could imagine this being a FCW.

The 8472: But you said tehy already do this to silence the warning, so they intentionally do something bad.

Nia: If they intentionally od something bad, it's fine to break them.

Waffle: I agree for the overlapping impls issue it's fine to break it. This does't affect the stable users.

Nia: With those caveats, if the crates that are broken are either intentionally doing hacky stuff or maybe they're leaf crates, we could handle them individually.

The 8472: Yes in that case we can go forward, but we should FCP it.

Nia: We definitely need to FCP it.

The 8472: Would you like to do this ahead of time or put libs on teh stabilization FCP?

Waffle: I'd prefer to have the sign-off ahead of time.

Nia: We'll leave this nominated to discuss this next week. Waffle, if you can't make it next week, drop a comment in the issue with the list of crates so we can check the popularity for.

Waffle: That's okay. I'll either work to analyze this myself or ping you with the next steps.

### (nominated) rust.tf/149926 `P-lang-drag-1` *Do not deduplicate captured args while expanding \`format\_args!\`*

Nia: Blocked on lang.

Josh: Have PMs renominate it when the lang stuff moves forward or if a couple of months passed?

Tomas: I'll do that (Edit: here's the comment: https://github.com/rust-lang/rust/pull/149926#issuecomment-4337888587)

### (nominated) rust.tf/152480 *\`format\_args!\`: only de\-duplicate captured identifiers that refer to places*

Nia: Blocked on lang.

### (nominated) rust.tf/153239 *Implemented DoubledEndedIterator for Ancestors\<'\_\> + added tests and updated doc comments*

Nia: Mark had a comment on the implementation being complicated here: https://github.com/rust-lang/rust/pull/153239#issuecomment-4322177474

The 8472: Components does some normalization, but I don't remember whether that's eager or on the first call.

Chris: I'm pretty sore it's done later.

The 8472: Then maybe the PR changes it to do it eagerly?

Nia: Mark suggests instead of custom logic it uses the same implementation as `Components` does.

The 8427: So `ancestors` has different logic and now it would be using `Components`? There's more things already using `Components` under the hood. Doing that is pretty widespread so using them here is probably not too surprising. Did any test results changed?

Nia: The old implementation didn't pass some fuzzing, but according to the author's last comment it passes all tests and fuzzing. But it's slower.

Josh: If this gives an implementation that's obviously correct and easy to understand that it's correct but slower that it might otherwise have been, then I'd merge it and if someone wants to make it faster and it passes implementation and it also passes the test suite, I'm all for it. Especially if this PR adds the fuzzer failures as tests.

Chris: There are a fair number of test cases being added here.

Nia: I don't think they specifically added tests for the cases the fuzzer caught. It checks the new logic. I think it's fair to request them if they can be minified.

The 8472: Regarding performance, I think `Components` has already been optimised.

Nia: It might also be how they're using it. They mentioned they're cloning it instead of `as_path`.

The 8472: I think some projects like Cargo are heavy users of `Path`s.

Nia: Does it make sense to profile Cargo with this change?

The 8472: I don't know if Cargo uses the ancestors. It uses `HashMap` and `BTreeMap`.

Nia: We can ping the Cargo people. Would this slow down iteration if it's not doing it as double ended?

The 8472: It's the same iterator.

Nia: I'm happy to type such a reply.

Josh: I'd say if they're not wildly bad I'd still want to do this. If it's a very slight performance effect but not substantial it's not a bad idea.

The 8472: I don't even know if Cargo specifically uses ancestors.

Josh: I'd ask for the addition of the tests derived from fuzzing and othervise accept as is.

The 8472: Going from 80k execs vs 60k is a significant slowdown, but in a real program it's probably a couple of percent. It would be nice to check but not a blocker.

### (nominated) rust.tf/153683 *Implementation of \`try\_from\_{nanos\_u128,mins,hours,days,weeks}\`*

Nia: teor nominated us for how we want to handle the error. I don't like the way the PR does it -- it changes the error from a stable one to an unstable one. teor recommended stabilizing `DurationConversionError` which might be a better approach.

The 8472: If it's stable, a breaking change is a no go for just a few new APIs.

Nia: I think the plan was that the `DurationConversionError` should get stabilized and `TryFromFloatSecsError` should become an alias. But we need to stabilize it.

Josh: I think we should go changing the alias. But there's also the concern of removing the `Display` impl. (Josh checks) I think it's been fixed so that comment gets resolved. We should just go ahead and stabilize the error. That seems fine.

The 8472: These new methods are unstable so we could defer stabilizing the conversion error until stabilizing these methods

Josh: We could, but that would defer making the alias. I'm inclined to stabilize the renamedb error and alias right away and stabilize themethods later.

The 8472: Can we have unstable aliases? We keep the old one and have the new one an alias

Waffle: Was this about a type alias or an alias as a `pub use`?

Josh: It's a type alias.

Josh: I feel this is a trivial rename. It globally rename `TryFromFloatSecsError` to `DurationConversionError` and have an alias for `TryFromFloatSecsError` an alias to `DurationConversionError`. I think it's fine to make this instastable.

Nia: I think that's what we discussed previously.

Josh: Yes. So let's just FCP the stabilization of the new name.

The 8472: That only makes sense if you want to stabilize the rest.

Nia: The reason was so these methods while they're unstable not having to return a different name. So there's less churn.

The 8472: If we can have an unstable alias, we can make the new name be the alias to the old name.

Josh: When we flip the alias, there are some cases in the compiler where it will resolve to the final name and reference to the final name. So you could have a type error that would show the old name while using this new method.

The 8472: Only on nightly. We'd flip it on stabilization.

Josh: IS your concern that we'd fail to stabilize the methods and this would be a churn?

The 8472: Yes.

Josh: Sure. If we want to do this we should only stabilize the error if we're confident that we'll stabilize the methods.

The 8472: Can we check if the unstable alias works?

Nia: Sure. We can try that, and if it doesn't work we can FCP an instastable `DurationConversionError`?

### (nominated) rust.tf/154374 *Rename \`MetaSized\` trait to \`SizeOfVal\`*

Nia: More suggestions were proposed. There are suggestions about the difference between storage size and alloc size in LLVM from Jacob.

The 8472: If some additional cases came up it makes sense to add them to the overview list so we can see how many of them are conflicts. E.g. `ValueType` is very general and can mean many things. But I'm not sure how fare they should go into the future.

Nia: I think the rationale is any of these might. And if we don't have names brought up we risk getting into the situation of already having picked names.

The 8472: That's why we should do a high level overview of what we might do even of things we're planning for later.

Nia: Fair. This is probably something we'd want to bikeshed in a meeting Amanieu is at too. But we should keep some source of truth of all the suggested things.

The 8472: Yes. There was a previous HackMD that goes into the depths of what all the things do. But we should also have a less detailed one that's focused on the names: what might exist and a two-sentence summary of what it is and what it's used for.

Nia: I think that's reasonable. We can set up an editable document so people can add naming suggestions or expand the sized hierarchy.

The 8472: Yes.

Nia: And we can look at that next week.

The 8472: I'll reply on the Zulip thread.

### (nominated) rust.tf/154665 *add safety sections for three functions in core::mem*

Nia: We'll need to give a comment on Mark's [comment on whether we want to sign off on guaranteeing a panic for `transmute_copy`](https://github.com/rust-lang/rust/pull/154665#discussion_r3105634625).

Nia: I think it's reasonable. This is basicaly the same guarantee we have fora normal transmute, but there it's a compile-time error.

The 8472: Didn't we discuss this last week?

Nia: We did. Judging from last week's notes, there was an idea about saying this might be a compiler error at some point in the future? I don't think we've finished the discussion last week.

Nia: My opinion is we should keep this as a panic and move this into a compiler error if that's supported by the new transmute stuff. But not keep it as UB. I'm not happy with the idea of allowing us to weakening it from a panic.

The 8472: We have different levels of compiler error: pre-monomorphization, etc.

Nia: I think it has to be post-mono or you'll get a lot of spurrious errors. Panic should be fine. This will error in some way, right now it's a panic but we reserve the right for it to be a compiler error.

The 8472: From users' perspective going from post-mono error to a runtime error. Post mono-errors leak out of branches while a runtime panic triggers only on that branch. So do we want to start with a runtime panic or start with a post-mono error?

Chris: Can we do a crater run to see the breakage?

Nia: There's the issue that we don't currently say anything about the size.

The 8472: The documentation says it's UB so we can do anything.

Nia: We can still say it's UB but say that we can guarantee it'll either be a panic or compiler error.

The 8472: Then we won't have to call it UB. If we have the UB we reserve the right to do anything including removing the check.

Nia: It would be nice to have the compiler error, but it depends on the new transmute.

Chris: We should be able to wrap it in a const block.

The 8472: Yes. The only thing that would affect the users was that if this was on a dev branch, it would now fail to compile what would compile previously. So we should do the crater run.

Nia: That's fair. If the crater run shows a lot of breakage we leave it as a panic and document that.

The 8472: UB says it's only UB if you reach it. So if you have runtime checks before you reach this code, it's not UB and we won't allow to do anything. So it would be the actual breaking change.

The 8472: Our choices are either keep this UB, guarantee a panic or try to push through some breaking change.

Nia: In light of that, I'd say document the panic, leave it like that. That's not going to break any behaviour -- it's what we have right now. And I don't see a nice path forward to making it an error. I don't see why this couldn't be an error, there are ways to do a full transmute if you need that.

The 8472: Since it's a new guarantee, we should FCP that.

Nia: I don't think we should openan FCP while Amanieu is not here, but we can write down our thoungns and if there's no opposition, we can start the FCP async.

### (nominated) rust.tf/155457 *Add a new type parameter to new \`Range\` types*

Nia: The stance from September was: "yes if it doesn't break inference". Since the tests are failing, I'm not getting confidence this isn't breaking inference.

Josh: That'd be my expectation as well. This will break inference on `0..variable_name`. Right now those are inferred to be the same type. I like the concept of being able to express a range that has different types on each end but in practice that seems hazardous from inference perspective. And I don't think we have any kind of fix for that.

Nia: The author's arguing this is only an issue when you're doing an edition migration and you can manually fix it. I don't like the idea that for the next edition you have to say `0i32..some_variable`

Josh: Exactly. I can imagine ways to try and make the inference better for that specific case. If it were just for `x..y` having different types, I'd be less concerned, but the literal `0..` I'd be concerned with. I could imagine making the inference for explicitly typed out literals. Imagine if the range syntax desugared to something that constraints to the two things that match their types and you'd have to do something extra for the mismatch cases. But that would defeat the purpose of this.

Nia: Agreed. I think this belongs to a library and if someone figures out to make it pretty, we could look into it then. I'd say no for now.

The 8472: I don't think you can do this as a library thing.

Nia: With a macro for the syntax.

The 8472: That would be very different.

Nia: Fair. But I'd like to see a proper sketch that doesn't break existing code, doesn't require ugly edition migration.

Josh: If it only had ugly edition migration but still let new code write `0..variable` that would be fine. But here even after the edition you wouldn't be able to write this.

Nia: Yes.

Josh: We should make this t-types nominated and write that we don't know how to make `0..variable` work and if types agree, I'd be inclined to close it. If they have an idea, we can try that idea.

Nia: I think I agree with that.

The 8472: The syntax inconvenience would be too much. Let's ask the types team.

Josh: I can write up a reply.

### (nominated) rust.tf/155527 *Replace printables table with \`unicode\_data.rs\` tables*

Nia: nominated because: https://github.com/rust-lang/rust/pull/155527#issuecomment-4322742762

> There is one change in behavior: we now consider all characters with the Default_Ignorable_Code_Point property to be unprintable. These characters can be hidden/invisible otherwise.

The 8472: Should we ping unicode experts?

Josh: I think we have a ping group for them, don't we?

The 8472: One of the things that are considered unprintable are variation selectors. But they're used in some emojis and flags? If we consider them unprintable and escape them, flags wouldn't work anymore?

Josh: To what extent do we treat an extended character (combining characters that produce an emoji) to be printable.

The 8472: Those are considered grapheme clusters and the stdlib doesn't have any logic about those.

Josh: sigh. What do we say is printability of the zero-width joiner?

The 8472: There's the combining grapheme joiner in the group as well. But tha's probably different.

Josh: If zero-width joiner is considered unprintable, that's something you have to have to use to write some emojis. If it is printable, I'd have concerns.

The 8472: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f64a2dd78aa82f19de0379a05fadfb1e

fn main() {
    let foo = "‍";
    dbg!(foo);
}

The 8472: It prints "\u{200d}" so it's already not considered printable.

Nia: Then it doesn't sound too problematic. It'd still be worth seeing if we have anyone with more unicode knowledge.

The 8472: If it's only `Debug` impls, that sounds good to me.

Nia: We don't guarantee the stability of `Debug` impls.

Chris: We have other escape methods. Would they be affected?

Nia: `escape_debug` is affected. I'll check that.

The 8472: It says it's the same as `char` `Debug` impl

Nia: In that case it's probably okay because we don't guarantee that.

Josh: I think we should start an FCP and also poke unicode folks and ask them to confirm whether this seems fine.

The 8472: From the API perspective: it's `Debug`, who cares. The other aspect is unicode-semantics.

Nia: I don't see a unicode ping group.

Josh: Then the only person on top of my head is Manish. And if we ping Manish, we should also ask to have a unicode group.

### (nominated) rust.tf/155750 *Document that \`ManuallyDrop\`'s \`Box\` interaction has been fixed*

Nia: It's nominated becaues we're committing to some stuff about `MaybeDangling`

Chris: It seems this needs a lang discussion.

Nia: It does but apparently it needs us as well?

Chris: If lang says "no" it'll definitely be a blocker.

The 8472: `ManuallyDrop` is not compiler magic, is it?

Josh: It's a compiler magic only in that "union" is compiler magic and this is a union. `MaybeDangling` is a compiler magic.

The 8472: If this is basically mostly compiler magic we should wait for Lang first. What are we deciding on even?

Nia: Even if we don't commit to `MaybeDangling` we should have something to prererve the behavior of `ManuallyDrop<Box<_>>`

The 8472: So if Lang says we approve of a mechanism for that, then we're asked to guarantee this?

Nia: I'm happy to reply that we can make the guarantee if lang signs off on that in the language. Is everyone okay with that?

### (nominated) rust.tf/155816 *Libs proposal: Policy for constifying traits and trait implementations*

Nia: I think we should have Amanieu for this.

Josh: I believe this came up on Zulip as well. Should we consider having more traits being constified? Part of the question was: are we willing to take PRs doing this?

Chris: I think it's more of a question for Libs. From the API perspective it's mainly nightly experimentation.

Josh: Assuming something's stably const, it does provide user-visible behaviour

Nia: We coudl always have the constness unstable.

Josh: Yes. If the trait constness is unstable then sure. I don't know to what extent e.g. if you say that operator traits are stably const you'd be able to invoke the operator. Even if we haven't stabilised the syntax of "my method needs a const operator" you can still specify a bound and require the property.

Chris: This is something they ripped out once and put it back again so I think it's safe enough.

Josh: I think at this point it's clearly shipping. I don't think it's getting reverted again.

Nia: I do still think as a whole that this is mostly a question for Libs. And for when there are a few more of us.

Josh: Libs as well as people doing libs reviews. So we might want to specifically ask Mark.

Nia: Yes. He did reply here in agreement mostly. And he also apparently wasn't sure this is libs api.

Josh: If Mark is okay with it, let's defer this to Libs.

### (waiting on team) rust.tf/153261 *Partially stabilize \`ptr\_alignment\_type\` as \`alignment\_type\`*

Nia: I think we said we can remove "waiting-on-t-libs-api" since there's not a lot we can do here. It's waiting on an FCP.

The 8472: The FCP has been started: https://github.com/rust-lang/rust/pull/153261#issuecomment-4164136648

Nia: Is everyone okay with removing "waiting"?

The 8472: Yes.

### (waiting on team) rust.tf/154905 *Derive \`Eq\`, \`Ord\`, \`Hash\` for \`MaybeDangling\`*

Nia: Why is this waiting on us and not just a nominated item? ... It's blocked on implementing stuff for `MaybeDangling`

The 8472: Waffle says it should implement as little as possible.

Nia: Do we want this to have the same traits as `ManuallyDrop`? With the justification that it'll be less footgunny if it does't.

The 8472: If they don't make sense we shouldn't make them in the first place.

Nia: It doesn't seem they don't make sense as much as how you do it. You could still do `Eq` on `MaybeDangling`, you'd just have to access the actual field and it's `Eq`. Or do a `Deref` and do an `Eq` on that. And `PartialEq` requires `StructuralPartialEq`

Nia: I'd say "no" for now. `MaybeDangling` is a half-baked mess so let's not make it easy to access the internal fields.

The 8472: Those are safe traits. If you can access the stuff safely, that wouldn't make sense?

Nia: It's making the derives all implicit instead of explicit. I don't have a strong opinion either way.

Nia: Tentative thumbs up? This is all unstable so let's put whatever you want on the unstable one

The 8472: That's not a good justification.

Nia: It simplifies the code and we're not committing to some API here.

The 8472: In unsafe simplifying is'nt always the goal. Sometimes you want to be really explicit on what you're doing. Or not have it at all. Looking at the implementations...

Nia: Previously we just did `.value.as_ref()` and just called the thing. I don't have a strong reason of being in favour but I also don't have a strong reason for being against.

The 8472: If there are any safety concerns in `MaybeDangling` they'd also apply to `ManuallyDrop`, but it all seems to be okay?

Chris: Waffle seems mainly against it and no one seems strongly in favour.

The 8472: `MaybeDangling` is an implementation detail of `ManuallyDrop`. So if it's unsafe on `MaybeDandling` it'd also be unsafe on `ManuallyDrop`

Nia: These are all safe. You can do it with safe accessors. I don't understand what's meant with unsafe here.

The 8472: Maybe let's ask for clarification. I don't know what's considered a "footgun"

Chris: I trust Waffle has reasons

The 8472: Let's make them explicit

The 8472: If we made it stable, we'd have to consider the saem things

Nia: If we made it stable. I don't think that's the plan for any time soon. But I'll ask for clarification.

### (waiting on team) rust.tf/155113 *Ensure Send/Sync impl for std::process::CommandArgs*

Nia: This is waiting on FCP. Josh and The 8472 please take a look post-meeting.

### (waiting on team) rust.tf/155153 *Ensure Send/Sync is not implemented for std::env::Vars{,Os}*

Nia: Also on FCP.

### (waiting on team) rust.tf/155528 *const\-stabilize \`char::is\_control()\`*

Nia: It's in the final comment period.

### (waiting on team) rust.tf/155705 *Add \`char::word\_to\_titlecase()\` to \`alloc\`*

Nia: This needs a sign-off from us because it didn't go through ACP.

Chris: What's the motivation?

Nia: Handling Greek, but I don't see a motivation specifically. But it's a tracking issue for handling `titlecase` in general. Why would this be under `char`?

The 8472: It's on `str`

Nia: The title implies it's a method on `char`

The 8472: It seems the title is incorrect.

Nia: This is part of an ongoing thing that we already signed-off on for titlecase handling.

The 8472: It's asking for an ACP extension. There's `to_titlecase` on `char` itself.

Nia: It'd be nice if there were usecases listed. But I'm not opposed to it even if they're not.

Nia: If you take a string of two upper cases and two lower cases ??

Josh: This is not specific to Greek. The common case is if you have languages that have single letters that are a combination of letters (ae, dz, ch). The difference is that uppercase will uppercase both and titlecase will do only the first one.

Nia: But in a lot of these cases there is a single unicode codepoint.

Josh: I was mainly trying to call out that this isn't just Greek.

The 8472: So this is basically about converting strings as well to titlecase. Word segmenting and then every first letter. I guess the test case could be better (e.g. "hello world" instead of just "hello")

The 8472: The general Libs API question is: do we want this? And since it's a unicode feature, why not?

Nia: I'm tempted to agree. There are languages where it's not-trivial for character clusters like Greek and for that I agree it's a good enough use case to allow this.

The 8472: It starts as unstable so we just need a consideration whether it has a chance

Nia: It has a chance:

Josh: :+1:

### (new change proposal) rust.tf/libs783 *Add std::range::DecreasingRange\* structs*

Nia: Seems interesting at first glance. But the syntax will be interesting to infer which range is correct. It'll probably need a different syntax than an invalid empty range.

Nia: Would this be mirroring all the existing Range types? What probably makes our work simple becaues they can just reverse that.

Nia: Including this would be predicated on having a nice syntax for this. No one's going to pull out the full types for this.

Josh: Agreed. As far as I can tell this is implying you'd type out `DecreasingRangeInclusive` which, no one's going to do that

The 8472: Usually you'd use autocomplete. But once you start with the curly brackets, struct syntax etc. it gets ugly

Josh: I think `..-` doesn't wokr because that could just be `..` to a negative number. `-..` doesn't work because it would be a subtration of `Range` which typechecks today.

Nia: `..v` or `..\/` where `v` is interpreted as a down arrow.

The 8472: A comment suggested adding `rev()` method on a regular range

Nia: That makes sense. You'd have to wrap the range in an extra parens, but that should be fine. And we could add the extra syntax later.

The 8472: The original statement talks about the "inclusion/exclusion of the start and end get flipped". Which one do they want to exclude? Is the start point supposed to be excluded?

Nia: That feels wrong.

Nia: Do we even have a Range that's not inclusive on the start?

The 8472: We have RangeBounds where you can have the lower bound. Is there a way to construct such a RangeBound? One of the impls of `RangeBounds` is tuples of the enums. You can construct those. So you can already express:

Today you can have `(Bound::Exclusive(0), Bound::Exclusive(100))` but `(Bound::Exclusive(100), Bound::Exclusive(0))` doesn't make any sense/doesn't get used.

Maybe we could have `Reverse((Bound::Exclusive(0), Bound::Exclusive(100)))` indicate what you want explicitly so there's no confusion. But there's no `Iterator` for this.

Josh: You could `IntoIterator` that, but by default it's not an iterator. But this is wildly longer than anyhting someone would want to write by hand. BUt I don't think we need a shorthand for writing an iterator with an exclusive start is.

Nia: Sure but I think it would be nice to have a short hand for a decreasing iterator.

The 8472: But the requested behaviour is not clear.

Nia: They want a slightly different behaviour. If you get `0..=4` and reverse that, you get `3, 2, 1, 0` and what they'd like is `4..-0` they'd want `4, 3, 2, 1, 0`

Josh: If we avoid floating point numbers would be to put the minus sign in the middle: `.-.`. The only downside is that if you wrote `4.-.0` you could lex it as `4. - .0` which could be `4.0 - 0.0`. We could change lexing

Nia: Dash is not allowed as a field name is it?

Josh: No, the only ambiguity would be a floating point.

The 8472: `slice.len() down to 0` ... you want the first one to exclusive... so flipping makes sense to me

Nia: I think the example they gave is a bit odd because they're using inclusive ranges. Inclusive range is fine, but exclusive range is trickier

The 8472: With the new range types are not invalid. It's just that the iterators don't do anything. We could have separate methods like `into_reverse_iterator`.

Nia: It makes sense if you think through it that a half-open range if reversed would also flip the bounds. But if I'm writing a countdown 5 .. 0, ?? I see where they're coming from that it should be the second element that should be excluded

The 8472: If you work with arrays a lot then you don't have this issue today because 0 is always in there.

Nia: That's fair.

The 8472: I can't imagine a use case right now. We should ask where the confusion is coming from. Because to me the very thing they're complaining about seems very useful to me.

Nia: Fair.

Nia: I think it makes sense to do this as a method rather than duplicating all the types.

The 8472: I'll ask them.

### (new change proposal) rust.tf/libs781 *ACP: Support \`NonZeroU16\` in \`ToSocketAddrs\`; \` SocketAddr\`'s \`From\` Implementation*

Nia: Why is not accepting `NonZeroU16` a problem? I don't necessarily see the case for this. The author directly says you can just do `.get()`. They address the `Into` idea but I don't think that should cause any breakages unless we get into some generics

Josh: I'd check what types we allow. We currently have quite a few implementations that take a "To" tuple that take ipaddr etc. But the second is always `u16`. I wonder if we add a second parameter, whether that breaks inference.

The 8472: I don't think type inference is as smart as you're concerned about. It might work because it doesn't do this magic.

Nia: There's the case that you have some other type you call 'into' and it'll figure out that the type is `u16` but now it could also be `Into<NonZeroU16`.

Josh: I'm testing that now. We talked about making an integer being `NonZero` in the future. I'd want to see a crater run. If there were no issues, Id' mostl y be fine with it. But I'd want to nominate it to types to explicitly ask if any of the potentially proposed changes around integers being `NonZero` would be made harder because of people now using this.

Nia: This is niche and it seems the main motivation of having to type `.get()`. And it would cause a combinatioral explosion.

Josh: Nobody is proposing we add this for e.g. u8 or saturating, wrapping etc. But having e.g. `Option<NonZero>>` for a port because port isn't ... but in the case of providing a default value you could just say `unwrap_or` so nevermind

Nia: The SocketAddrPort can be set to zero.

Josh: Fair enough. You can just use `.into().get()`. It's not an unreasonable ask, I can see why someone would want it. But it's sufficiently niche and how it'd break inference. But I'm still almost tempted to do a crater run and do it if it comes back clean.

Nia: I don't feel particularly strong but I'd be open to that.

The 8472: I wrote some socket code but only a small part of an application and I wouldn't have benefited significantly.

Josh: I could go either way.

Nia: ...sure. I feel very weakly towards closing it.

Nia: This would be "crater check" run, right?

Josh: I can write it up.

### (new change proposal) rust.tf/libs780 *ACP: \`OsStr::{split\_at, split\_at\_checked}\`*

### (new change proposal) rust.tf/libs779 *floating\-point NaN payload functions*

### (new change proposal) rust.tf/libs778 *ACP: Add \`char::to\_u32\` to access underlying value*

### (new change proposal) rust.tf/libs777 *ACP \`Vec\<u8\>::push\_utf8\` for no\-memcpy UTF8 in a general bytes buffer*

### (new change proposal) rust.tf/libs775 *\`unchecked\_wrapping\_rem\` and \`checked\_wrapping\_rem\` for \`iN\`*

### (new change proposal) rust.tf/libs774 *Combined \`div\_rem\` function (and variants) for ints and uints*

### (new change proposal) rust.tf/libs773 *\`ptr::sentinel\`: \`ptr::dangling\` that cannot alias valid pointers*

### (new change proposal) rust.tf/libs771 *introduce an accessor method for \`std::fs::ReadDir\` that lets us get the path associated with the \`ReadDir\` iterator*

### (stalled change proposal) rust.tf/libs210 *Add associated consts to f32, f64 for mathematical constants*

### (stalled change proposal) rust.tf/libs322 *\`AssertThreadSafe\` (name TBD) – a more general API for lifting conservative \`!Send\` or \`!Sync\` implementations*

### (stalled change proposal) rust.tf/libs331 *Support permanently skipping tests on a specific system*

### (stalled change proposal) rust.tf/libs457 *APC: split\_pattern on slices*

### (stalled change proposal) rust.tf/libs246 *ACP: replace use of \`Pointee\` trait with a \`ptr::Metadata\` type*

### (stalled change proposal) rust.tf/libs296 *ACP: Designing an alternative \`FromStr\`*

### (stalled change proposal) rust.tf/libs334 *Customizing \`#\[derive(Debug)\]\`*

### (stalled change proposal) rust.tf/libs452 *ACP: Implement \`TryFromIterator\<T\>\` trait to compliment \`FromIterator\<T\>\` trait.*

### (stalled change proposal) rust.tf/libs462 *impl fmt::Write for BufWriter*

### (stalled change proposal) rust.tf/libs207 *\`parse\_line\` method for \`Stdin\`*

_Generated by [fully-automatic-rust-libs-team-triage-meeting-agenda-generator](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator)_