# Libs-API Meeting 2024-08-13 ###### tags: `Libs Meetings` `Minutes` **Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr **Attendees**: Amanieu, David, Mara, Josh, Chris Denton, The 8472 ## Agenda - Triage - Anything else? ## Triage ### FCPs 7 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/123723 *Make \`std::os::tvos\`, \`std::os::visionos\` and \`std::os::watchos\` public* - (3 checkboxes left) - merge rust.tf/120141 *Tracking Issue for enum access in offset\_of* - (6 checkboxes left) - merge rust.tf/114298 *Tracking Issue for \`char::MIN\`* - (3 checkboxes left) - merge rust.tf/65225 *Tracking issue for \`#!\[feature(entry\_insert)\]\`* - (3 checkboxes left) - merge rust.tf/128711 *impl \`Default\`, \`Clone\` for \`HashMap\`/\`HashSet\` iterators that don't already have it* - (3 checkboxes left) [dtolnay (1)](https://rfcbot.rs/fcp/dtolnay), [pnkfelix (1)](https://rfcbot.rs/fcp/pnkfelix), [scottmcm (2)](https://rfcbot.rs/fcp/scottmcm), [BurntSushi (5)](https://rfcbot.rs/fcp/BurntSushi), [m-ou-se (4)](https://rfcbot.rs/fcp/m-ou-se), [joshtriplett (3)](https://rfcbot.rs/fcp/joshtriplett), [tmandry (1)](https://rfcbot.rs/fcp/tmandry), [Amanieu (2)](https://rfcbot.rs/fcp/Amanieu), [nikomatsakis (2)](https://rfcbot.rs/fcp/nikomatsakis) ### (nominated) rust.tf/libs355 *Add "as raw pointer" methods to \`Box\`* Mara, Amanieu: looks fine ### (nominated) rust.tf/122670 *Fix bug where \`option\_env!\` would return \`None\` when env var is present but not valid Unicode* Options: 1. hard error 2. keep current behavior (None) 3. lint and None a. warn-by-default? b. error-by-default? c. lint and to_string_lossy? Mara: Prefer option 1 Amanieu: Not a big deal, because all compile time Amanieu: Prefer option 3. Josh: leaning towards 1. "None" is 'this was not present', not 'some mangled (non-unicode) mess'. use of option_env is not to ignore things that are invalid. The 8472: The documentation today says it will never give an error > _"A compile time error is never emitted when using this macro regardless of whether the environment variable is present or not."_ Mara: People use `option_env` if None has a meaning. We shouldn't trigger that None behaviour when it *is* present but with invalid data.. Amanieu: https://github.com/search?type=code&q=language%3Arust+option_env Mara: People clearly assume that `None` maens 'not set', not 'broken' David: Agree with Josh and Mara, that None should only mean 'not set'. The 8472: Some people just compare it to a fixed value. Giving a compile error then is unnecessary/unwanted. David: Let's start with a hard error, and then people can come with a reason if they want a lint instead. David: cap-lints would cap this lint if it was a lint. Josh: then it shouldn't be a lint Mara: +1 Josh to reply. ### (waiting on team) rust.tf/119550 *Rename \`AsyncIterator\` back to \`Stream\`, introduce an AFIT\-based \`AsyncIterator\` trait* Waiting on WG-async ### (new change proposal) rust.tf/libs428 *Rangeless Shifts* Mara: counterproposal: change `<<` and `>>` themselves, instead of a new method Amanieu: opposed for performance reasons; on all platforms I know of there is no efficient way to implement the new behavior Amanieu: in practice, all shifts are in range, so it doesn't make sense to apply a performance overhead to _all_ shifts Mara: curious whether it makes a difference in real code, since the compiler will almost always be able to see the shift is in-bounds, such as given by a loop 0..=31 Josh/Amanieu/The 8472: we shouldn't change the operators, they should results in a single instruction, for performance. David: In my view, the role of the operator is to do the thing what most people want. 99% of shifts that people write are not performance sensitive. and for those that are, most of them can be optimized. The people left in the remaining 0.01% where the performance matters and the optimization doesn't happen, they can use a named method. Mara/David: This behaviour change of the operators is not a new idea. It came up before. David: It would address a few bugs i've had in code before. Conclusion: have these as unstable with a better name. lang discussion for operator behaviour before stabilization. David to reply. ### (new change proposal) rust.tf/libs427 *Introduce an async util \`WaitGroup\`* Please file an issue for futures-rs, ACPs are only for the standard library Amanieu to comment ### (new change proposal) rust.tf/libs426 *Add \`PathBuf::into\_join\`* Understand the motivation, dislike the proposed name (this happens a lot) The 8472: We shouldn't add a `self->Self` method for every `&mut self` method. Needs a general solution, like `tap` or lang or something. Mara: +1. Otherwise we also need `into_pop`, `into_set_file_name`, ... David: At work we use `path_macro`, `path!(a / b / d)` to compute a path in one allocation. David: We rejected adding a division operator, but a path! macro would make sense. David: It doesn't take ownership of any allocations, but we could do that. Require `&` for not consuming. The 8472: How about `\` on windows? David: DSL has `/`, but PathBuf::add will add `\` on Windows. Mara: Unclear to me if the macro should support e.g. set_extension or set_file_name. David: path!() is not used for performance. The ACP seems premature optimization. Mara: `path!("{dir}/file_{n}.jpg")` wouldn't be possible. Seems underpowered if we only support `path!(dir / "file.jpg")` Josh: `path!(dir / format_args!("file_{n}.jpg"))` ? Conclusion: We don't want into_join. Premature optimization? Might be interesting to explore a more general solution with a macro. The 8472 to reply. ### (new change proposal) rust.tf/libs425 *\[ACP\] Make it no need to customize both \`Ord\` and \`PartialOrd\` manually* ### (new change proposal) rust.tf/libs424 *ACP: impl From\<&mut {slice}\> for Rc\<{slice}\> and Arc\<{slice}\>* ### (new change proposal) rust.tf/libs423 *ACP: \`PtrRange\<T\>\` type* ### (new change proposal) rust.tf/libs422 *Additional BufReader API for incremental buffer filling* ### (new change proposal) rust.tf/libs421 *Implement \`IntoRawX\`, \`FromRawX\` and \`AsRawX\` for \`RawHandler\` and \`RawSocket\`* ### (new change proposal) rust.tf/libs420 *Add basic tempfile API to stdlib* ### (new change proposal) rust.tf/libs419 *Enable specialisation of \`std::io::copy\` for non stdlib types* ### (stalled change proposal) rust.tf/libs287 *ACP: Add \`FromByteStr\` trait with blanket impl \`FromStr\`* ### (stalled change proposal) rust.tf/libs255 *Adding \`set\_route\` to \`sys::unix::net\`* ### (stalled change proposal) rust.tf/libs298 *Constructive/Destructive Interference Size Padding* ### (stalled change proposal) rust.tf/libs246 *ACP: replace use of \`Pointee\` trait with a \`ptr::Metadata\` type* ### (stalled change proposal) rust.tf/libs207 *\`parse\_line\` method for \`Stdin\`* ### (stalled change proposal) rust.tf/libs230 *Add \`saturating\_shl\` and \`saturating\_shr\` for ints* ### (stalled change proposal) rust.tf/libs111 *Restructure ptr\_metadata to minimal support* ### (stalled change proposal) rust.tf/libs184 *Add \`setsid\` method to \`CommandExt\` trait* ### (stalled change proposal) rust.tf/libs253 *Provide way to deconstruct std::iter::Rev* ### (stalled change proposal) rust.tf/libs257 *Implement \`From\<&'a &'static str\>\` for \`Arguments\<'a\>\`* ## Extra meeting slot Amanieu: We've only been able to go through 4 acps this meeting, but there are 10 new ones. We need more time to process ACPs. Extra meeting? Amanieu: Based on the poll, we got two reasonable slots. 1. Immediately after this meeting. Extending this meeting to 3-4 hours. 2. After the libs meeting on wednesday. Josh: Make this meeting 2 hours every week, instead of every other. Mara: My working day normally ends about an hour ago, when half of y'all aren't awake yet. But I don't mind you all meeting without me. Conclusion: Start with making this a 2 hour meeting every week.