# Libs-API Meeting 2023-07-25

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

- merge rust.tf/88581 *Tracking Issue for \`int\_roundings\`* - (1 checkboxes left)
- merge rust.tf/80437 *Tracking Issue for \`box\_into\_inner\`* - (1 checkboxes left)
- merge rust.tf/91946 *Tracking Issue for \`io::Error::other\`* - (3 checkboxes left)
- merge rust.tf/98461 *Document lack of panic safety guarantees of \`Clone::clone\_from\`* - (0 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* - (4 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/107587 *Mark \`std\` integral modules as deprecated (\`std::u32\`, \`std::i16\`, etc.)* - (4 checkboxes left)
- merge rust.tf/113701 *Re\-export core::ffi::FromBytesUntilNulError in std::ffi* - (4 checkboxes left)
- merge rust.tf/62726 *Tracking issue for io\_slice\_advance* - (3 checkboxes left)
- merge rust.tf/88561 *Allow redirecting subprocess stdout to our stderr etc.* - (3 checkboxes left)

[yaahc (4)](https://rfcbot.rs/fcp/yaahc), [Amanieu (5)](https://rfcbot.rs/fcp/Amanieu), [joshtriplett (5)](https://rfcbot.rs/fcp/joshtriplett), [m-ou-se (7)](https://rfcbot.rs/fcp/m-ou-se), [BurntSushi (9)](https://rfcbot.rs/fcp/BurntSushi), [dtolnay (3)](https://rfcbot.rs/fcp/dtolnay)

### (nominated) rust.tf/102070 *Tracking Issue for \`ptr::Alignment\` type*

Request for FCP.

(Fixed tracking issue: `Magic` -> `Alignment` (leftover from template))

David: This is entirely self-contained, not used in any API, correct?

Amanieu: yes

Amanieu: what was the use case for this API?

thomcc: we use it for Layout. not sure if we should stabilize it..

the 8472: right now you can specify any usize as the alignment in layouts. i assume that should use this type instead? not sure.

david: the last comment on the tracking issue shows someone has a use case for it.

amanieu: it's a shame the Layout methods all use usize.

amanieu: i'd like to see this type used more in std.

amanieu: i think i'm against stabilizing this. if it's not used in std, it can be in a crate.

mara: i'm for stabilizing these, aiming to use them in std afterwards.

amanieu: i'd stabilize them together, not this on its own.

mara: makes sense.

david: what's the error type for the tryfrom/tryinto impls?

amanieu: tryfrominterror

david: might be the wrong error type

{some discussion on the implementation of the type}

### (nominated) rust.tf/113859 *Add note that Vec::as\_mut\_ptr() does not materialize a reference to the internal buffer*

Amanieu: what does 'matierlize a reference' mean?

thom: doesn't invalidate existing references. this is the reason Vec has its own method, instead of relying on Deref to slice.

amanieu: generally, this is fine from libs-api perspective, but the wording is atrocious. many people will not understand it.

the 8472: those who care will understand it

amanieu: sure, but perhaps it could link to the provenance docs.

thomcc: agree it needs rewording

mara: maybe it can use an example.

no objections.

thom to reply/review.

the 8472: this needs an FCP

### (new change proposal) rust.tf/libs220 *Implement \`From\<{&,&mut} \[T; N\]\>\` for \`Vec\<T\>\` where \`T: Clone\`*

david: i think we can accept this.

amanieu: seems fine.

amanieu to reply.

### (new change proposal) rust.tf/libs228 *ACP: Bigint helper methods*

Already has a tracking issue. No need for an ACP. Left a comment and cosed.

### (new change proposal) rust.tf/libs230 *Add \`saturating\_shl\` and \`saturating\_shr\` for ints*

mara: 1 << 1000 is MAX or 0?

david: discussed last time. MAX, not 0.

mara: maybe a bit confusing, because `wrapping` in `wrapping_shl` is about the bit count, not about the result value. but here `saturating` is about the result, not the bit count.

mara: arguably, 1 << 1000 with the operator should just return 0, instead of panicking (debug) or using 1000%BITS (release).

mara: does .saturating_mul(1 << N) work and compile to the same? that's clearer

amanieu: that doesn't work for large N.

mara: right

the 8472: when do you need that?

mara: what are the use cases? Oh, already asked last week.

TC: Can think of some cryptographic operations that may be able to use that.

The 8472: can you post them in the ACP?

mara: how does this work for signed ints? e.g. 0b010000... << 1? is the result positive or negative?

amanieu: that becomes positive max: 0b0111111..

mara: so you can never shift any bit into the sign bit with this method.

amanieu: yes.

mara: that makes it feel like it shouldn't be called 'shift', but rather `saturating_mul_2_pow` or something like that.

josh: agreed

no consensus today. amanieu to reply

### (new change proposal) rust.tf/libs231 *ACP: Add const fn TypeId::matches for comparing type ids in consts*

david: this is equivalent to just PartialEq, but in const, right?

thom: yes

david: any chance we can just make `==` work in const for this type? like for ints? i'd prefer that over adding this as a workaround for const.

mara: i'd expect that's tricky to hack into rustc, but not sure.

thomcc: might be hard. int `==` doesn't go through the trait at all.

josh: oli said we might be able to do something without waiting for full const traits.

https://github.com/rust-lang/libs-team/issues/231#issuecomment-1581643761

amanieu: so, conslusion, we prefer `==` over a separate method

david: if we don't support `==` and accept this method, will we get many more requests for similar methods (which will all be tech. debt)?

mara replied.

### (new change proposal) rust.tf/libs247 *Proposal: Add OsStr::to\_mut\_str and OsString::to\_mut\_string*

the 8472: this can be done today with the as bytes method

amanieu: how do you impl this?

mara: OsString and String would need to have identical layout.

mara: i can't think of any use cases for this method that don't feel like an anti-pattern.. if you know that your OsString is valid utf-8, shouldn't you be using String instead?

..: camino wraps OsString/PathBuf, not String.

mara: i don't think we want to guarantee OsString and String have the same layout. and the OsStr method can already be done with the bytes method.

amanieu: i do think camino can just wrap String. doesn't seem like they expose &PathBuf or something like that.

amanieu to reply

### (stalled change proposal) rust.tf/libs148 *Expose raw std{in,out,err}*

mara: StdoutRaw on windows isn't very 'raw'. it doesn't lock, but it does have a buffer to reconstruct utf16 from the utf8 stream, depending on whether the output is a console or not. it doesn't seem as 'raw' as the thing they are actually asking for.

amanieu: on windows you can write ascii as [u8] to a console handle, but that won't work for unicode. will work fine for a file that.

mara: but that's not what you get if we just expose StdoutRaw

josh: is there a newer windows api that makes this better?

chris: not anything we can use any time soon

mara: left a note about the windows situation.

conclusion: needs more discussion

### (stalled change proposal) rust.tf/libs146 *ACP: \`impl TryFrom\<char\> for u16\`*

the 8472: i don't like this one. it makes assumptions about charset..

mara: we already have that for u8..

the 8472: yes, but this is worse. for u8 the choice is obvious. for u16, it's not obvious.

mara: isn't this the only obvious way to do this?

josh: i can think of two ways: 1. accept surrogates, 2, don't

mara: that's not possible, chars can't represent half of a surrogate pair.

mara: so there only seems one obvious conversion

josh: try_from from u32 works though.

mara: that applies to u8 too. and i'm saying that the conversion to u8 is less obvious than the conversion to u16.

josh: will this result in anti-patterns?

mara: better than doing u32 -> as u16. seems fine.

the 8472: at least we should have a doc comment about this not resulting in utf16, just ucs-2.

josh: seems fine.

the 8472: we should encourage utf16 over ucs-2..

mara: it's better than `as u16`

the 8472: scott does propose the `encode...` method

mara: it's not encoding. it's the same as the TryInto u8 impl we already have.

josh: objections to adding the trait impl?

the 8472: just a general feeling that i don't like it. no solid arguments other than ucs-2 being more niche than ASCII and the u8 conversion.

mara: the u8 conversion is 256 code points, not just the 128 ascii ones.

mara: this needs to be an FCP. let's ask for a PR?

josh + david: :+1:

mara replied.

### (stalled change proposal) rust.tf/libs145 *ACP: Additional NonZero conversions*

josh: these look fine

mara: yeah. but this is the same issue we discussed before, of all the 'ref/slice of X to Y' explosion, like with MaybeInit etc.

david: so like we'd also need from &T to &Wrapping\<T\> etc.?

mara: yeah exactly :( (e.g. &[u8] to &[MaybeUninit<Wrapping\<u8\>\>] or w/e)

david: do we defer this until safe-transmute or something exists?

josh: would we have accepted this if this was a more limited propsal?

mara: i think im fine with all the triat impls here. it's just another reminder that we need someting better for these 'explosions' of impls.

mara: scott mentions that safe-transmute is bitpattern preserving, e.g. i32 to f32. defering to that works and is safe.. but is not really the right solution for e.g. NonZeroU8 to U8 to Wrapping u8, etc. Perhaps we need something else.

### (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)_