# Libs-API Meeting 2023-06-20

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

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

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

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

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

### (nominated) rust.tf/111884 *Clarify intended use case for From/TryFrom/Into/TryInto*

Mara: Doesn't seem to need an FCP?

David: Skeptical about this wording.
Example: `From<String>` and `FromStr` impls for `Json`: one makes a Json::String, other one parses json. Hard to explain the difference.
Perhaps this documentation needs clear examples.

The last sentence (about i32<->String) seems to capture the idea well, but that's not captured well by the rest of the text.

'semantically equivalent' isn't the right wording, as it's often used to go from 'subset' to 'superset' (like the Json example).

David: maybe the 'values' are 'semantically equivalent' intsead of the 'types'? unclear if that's the right wording.

Josh: Lossless?

Mara: Maybe it shouldn't be lossless, because e.g. converting Token to String (losing span information) seems fine.

David: Agreed

The 8472: Lossless can still be useful as a guideline, even if it isn't an universal rule.

Mara: Another example: Cow. Cow->String loses the 'was it borrowed' bit (which is probably not what you care about if you convert to String).

David: Maybe we can relate it to PartialEq? You shouldn't be able to start with 2 values that PartialEq says are not equal, run From conversions on them, and end up with 2 values that PartialEq says *are* equal.

Josh: We don't have TryFrom<IpAddress> for Ip4Address.

Mara: I don't think that'd be wrong to have. (But it might not meet our treshold for 'is it worth adding that'.)

Josh to reply.

### (nominated) rust.tf/112423 *std::process:\:Child::kill should not fail if process is terminated on Windows*

FCP started. (Andrew raised a concern, which was resolved.)

### (nominated) rust.tf/112773 *Accept ... in format macro parser*

Reject using `}` as fill character?

Amanieu: It *feels* like it should be parsed as the closing brace.

Mara: `{:}` just works today. Only `{:}>` does not.

Mara: We already accept `{:}>10}`.

Mara: If there are no formatting options, don't specify the `:`. We can just improve the diagnostic.

Amanieu: Was this accepted by accident?

Mara: This is intentional to accept any char as fill char.

This PR is a breaking change. Today you can specify `}` as fill char. After this PR you cannot.

The 8472: ```{:}<3}``` already works. It fills up to three `}` charcters.

Mara: `{:}` used to trigger a clippy lint, to replace it with `{}`.
I broke that lint. Suggestion was to make it a rustc lint. Maybe that can cover this case too.

Josh: Should we close this PR, since it's breaking?

Mara to reply

### (waiting on team) rust.tf/94748 *Add \`Read\`, \`Write\` and \`Seek\` impls for \`Arc\<File\>\` where appropriate*

Went into FCP. Relabeled.

### (waiting on team) rust.tf/107587 *Mark \`std\` integral modules as deprecated (\`std::u32\`, \`std::i16\`, etc.)*

David replied last week, about not deprecating but doing some other form of suggestion. Reactions seem positive.

David: Might not be worth implementing this '#[legacy]' idea, could be a lot of work.

Mara: Doesn't seem like much work to add `#[deprecated(severity="legacy")]` with a tweaked message.

David: It might need more than that to have the right suggestions, e.g. removing the import without touching the usage.

Josh: could we give more examples of where you'd use this 'legaacy' feature, and give some general documentation explaining the distinction for when you'd use one and when you'd use the other?

Mara: It could be a specialized lint. Plenty of people are excited to implement new lints. Maybe a clippy lint and then uplift it later.

Josh: "severity" doesn't sound right, that seems relevant for e.g. deprecated unsafe/safe too

Let's aim for a clippy lint for now.

### (waiting on team) rust.tf/111347 *Add \`Future::map\`*

Just waiting on review.

### ACP meta

Amanieu: Should we move the ACPs to the wednesday meeting?

Mara: Or nominate ACPs before the meeting starts?

David: Or make this meeting longer?

Amanieu: Making it longer would overlap with other meetings. (on odd weeks)

Mara: Just extend it only on even weeks?

Amanieu: sure

David: :+1:

Conclusion: 2 hour meeting instead of 1 in the even numbered weeks. Starting next week. With a cut off to start talking about ACPs in the second hour (or sooner).

### (new change proposal) rust.tf/libs236 *Implement \`PartialEq\`, \`Eq\`, \`PartialOrd\`, \`Ord\`, \`Hash\` for unix \`SocketAddr\`*

Josh: I want this :)

Mara: Two weeks ago we were wondering if we should just expose the raw bytes instead.

Josh: Then you could still not derive PartialEq on your struct containing an address.

The 8472: What about 'not an address', should that behave like NaN or should that compare equal to itself?

Josh: I think those should compare equal

{more discussion on that}

..

The 8472: Two connections can both result in an unnamed socketaddr, so those would be collapsed into one in a map?

Mara: Is it platform specific, whether you get a 'not an addr' address or not?

Mara: `SocketAddr` behaves like an 'Option'. creating a map with keys for SocketAddr will have one entry for the 'none' case.

Josh: Maybe only PartialEq and Eq? Not Hash and Ord?

The 8472: That still has the issue

Josh: don't agree it's an issue, is_unnamed SocketAddr values should compare equal, that seems semantically correct for `SocketAddr`.

### (new change proposal) rust.tf/libs237 *thread::sleep\_until, wait until a deadline is reached*

### (new change proposal) rust.tf/libs238 *ACP: \`NonNanFNN\` and \`FiniteFNN\` float wrappers*

### (new change proposal) rust.tf/libs241 *Make \`Box\` comparisons independent of allocator choice*

### (new change proposal) rust.tf/libs242 *proc\_macro: Implementation of Extend (parameterized over Group, Ident, Punct, and Literal) for TokenStream*

### (stalled change proposal) rust.tf/libs116 *Lossy UTF8 conversion of owned types (\`Vec::\<u8\>::into\_utf8\_lossy\`).*

### (stalled change proposal) rust.tf/libs124 *Integrate \`Error\` trait with panic interfaces*

### (stalled change proposal) rust.tf/libs119 *ACP: Add a constant for the golden ratio (phi) to the floating point types*

### (stalled change proposal) rust.tf/libs115 *ACP: Range::cmp\_scalar; comparison (less/equal/greater) to a primitive of the Range*

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