# 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.