---
date: 2024-04-09
url: https://hackmd.io/wp8UHXkBSgyZLqB9uXMh3g
---

# Libs-API Meeting 2024-04-09

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

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, Josh Triplett, David Tolnay, Mara, The 8472, Cornell Kuhnke, Eric Holk, Chris Denton, TC

## Agenda

- Triage
- Anything else?

## Triage

### FCPs

1 rust-lang/rfcs T-libs-api FCPs

- merge rust.tf/rfc3550 *RFC: New range types for Edition 2024* - (4 checkboxes left)

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

### (nominated) rust.tf/rfc3550 *RFC: New range types for Edition 2024*

Document to read: https://hackmd.io/@uhs6rVdLTSS0gnie4q0fqA/ryjYJW2pa

Questions while reading:

eholk: It says the `ExactSizeIterator` impls are incorrect when `usize` is not 64-bits. In what ways are these impls wrong?

- Mara: ExactSizeIterator::len() needs to return an accurate usize. Doesn't actually fit if usize is too small.

Amanieu: The suggested migration for `takes_range` is

pub fn takes_range(range: impl Into<range::legacy::Range<usize>>) { ... }

Wouldn't it be better for this to be `Into` the new range type so the legacy types aren't encouraged to appear in new API?

Josh: Is the proposal to have `From` impls in *both* directions, or only from the new to the old? (Also relevant for the question above.)

- Mara: I'm guessing it's only one direction, because in the other direction you can lose information (the extra bool for RangeInclusive).
- Josh: Could we have the `From` impls that *don't* lose information, which would cover the common case of `Into<std::range::Range<usize>>`?
- David: The RFC specifies `From` in both directions, with `TryFrom` for one direction of the RangeInclusive case
- Mara: Oh right, misread.
- Amanieu: So i guess the answer to my question is yes.

Amanieu: Why is type inference not being proposed as the primary solution? What are the downsides? (I suppose it's just language complexity that we need to support forever)
- Mara: Design complexity. If not necessary, it saves a lot of work that requires a lot of types expertise.
- David: Not clear we should use the same mechanism as integers. Those fall back to i32 very quickly, probably more than what we want here.

eholk: What are some examples of previous changes that crate authors did not receive well?
- Mara: resolver = "2" that required some crate maintainers (diesel iirc??) to make changes because their users switched to the new edition, even when they did not do that themself.
- Josh: Bit different. It's not forced on them (the way diesel *had* to support resolver = 2 or break), but there is likely to be demand.

eholk: Would adding some kind of auto `into_iter` mechanism work?
- Mara: Maybe?
- eholk: incomplete idea, but might be simpler.
- Amanieu: sounds like something very subtle.
- Mara: Doesn't solve the `Range: Copy` issue.
- Amanieu: implicit type conversion isn't easily added to Rust.
- TC: Would not be in time for Rust 2024.
- Mara: FWIW, Rust 2024 might become Rust 2025.

Josh: Integers are the other place where we currently use this kind of type inference, and that seems like it has been a source of confusion, as well as one of the few things that isn't really expressible in the type system (you can't actually write the pseudo-type of an integer). Could we turn this into something expressible with a trait, and have some kind of "default impl of the trait" that has the same effect as the proposed type inference change?

- Mara: you're basically proposing making `1..2` expand to `Range(1, 2).into()`, where `into()` is some trait method. (Or another trait/method.)
- Josh: Yes, basically. Or another trait.

Josh: This may have been covered before, but what prevents us from using the same types for the types other than `RangeInclusive`? What would break? (Would it be "allowed" breakage?)

- Mara: 1: Having Copy + Iterator on the same type. Can result in some situations where you work on a copy rather than advancing the original.
- Mara: 2: The ExactSizeIterator problem.

Example of 1:

let mut range = 0..10;
for x in range {... break ...}
range.next() // ???

- Mara: I feel like a lint could catch that.
- David: We should discuss the option of just adding Copy and a lint. What would be left?
- The 8472: wrong ExactSizeIterator is an issue for iterator adapters.
- Mara: Other thing is the extra bool in `RangeInclusive`
- Josh: We can do an edition migration for just RangeInclusive.
- Mara: Another partial solution is to change the bool to an Option on either of the bounds.
- David: I'm hesistant to make RangeInclusive an argument for this RFC. The performance impact on that doesn't justify the change.
- Amanieu: I have often created a custom range type because the standard one is unusable.
- Josh: Same

The 8472: How about mutable references? Those are more problematic. Then both sides need to convert.

- Mara: Great point. I don't think this has been discussed before. Might want to comment on the RFC
- Amanieu: Probably not that common though.

eholk: Can we add range type inference later?

- Mara: Sure, but that doesn't really solve the issue. Then we still have a period of time when things are messy.
- Amanieu: Should still happen before the edition is released.

TC: If lang did not (immediately) change how the `..` etc. syntax desugars, how would libs-api feel about adding these types now (the RFC proposes adding these types as soon as possible to give the maximum possible time for migration)?

- Mara: I don't think we should add it unless we are sure of the plans for `..` to use the new types. Having these types in `std` probably doesn't make sense unless they are used for a language feature. E.g., an `RGB` type could be useful, but shouldn't be in std.
- TC: Broadly, as a matter of process, I'm trying to work out what is owned by lang and what is owned by libs-api here. Someone needs to own the tradeoff between the cost of the migration and the benefits to the language. If the only reason these would be in the standard library is due to support for the language feature (as you suggest), then that may suggest more lang ownership.
- Mara: libs-api is invovled for two reasons: 1: changes to std. 2: to establish the impact on the ecosystem which lang asked us to do.
- TC: In my view, lang asked the second question due to the concern that had been raised on the libs-api side.
- Mara: The concern is mine, not libs-api.
- TC: That would be worth clarifying, in terms of whether libs-api would adopt your concern, because (in my sense) lang may have understood this concern as a blocker for libs-api.

Mara: How the rest of does libs-api feel about the RFC as currently proposed? (Without type inferrence etc.)

- Amanieu: I would like to see type inference support because this eliminates a large part of the migration effort for the community. In total it's less work to do this migration work on the rustc side.
- Josh: Support for some kind of solution that doesn't require the ecosystem to migrate, but I'm not sure that such a solution would get implemented. And I don't think I'd block the RFC as proposed even without such a solution on offer.
- David: Prefer the RFC largely as written, but open to someone prototyping a type inference trick to show it can work well enough

Mara: In general, how do we feel about expecting library maintainers to needing to prepare their crates for the new edition?

- Mara: I personally think this is a bad direction, but would love to hear what everyone thinks.
- Josh: In general, that seems OK, as long as the library maintainers understand the rationale for the change and feel like it's worthwhile.
- David: I'm fine with being asked to support new std types; that happens regularly (e.g. please add serde impls for `OnceLock`). The difference in this case is we need crate authors to make breaking changes to existing APIs, not just add impls.
- Eric: How would we feel about making or not making this change in 10 years?
- Amanieu: If the ranges were done as proposed in Rust 1.0, then people would use those range types a lot more. That's a good thing.
- Mara: I agree that it's simple if we can go back in time, but the point here is whether the messy transition period is worth it to get there.
- Mara: If a new Rust user in say two years from now writes a new crate, they will probably be expected to support the old range types that they might not even know about. We need to have a clear story and clear documentation here, but the situation is messy.
- Josh: Seems fine to not support the old range types.
- TC: +1, editions are meant to be adopted.
- Josh: Let's give guidance for crate maintainers, for both existing and new crates.

Mara: How long should the period be between stabilizing the new range types, and changing the meaning of `..` in the new edition?

- Josh: How long do we want to keep the new types unstable on nightly before stabilizing?
- Amanieu: I don't think anyone will bother using the new types until the edition is available on nightly.

(The meeting ended here.)

---

### (nominated) rust.tf/121920 *downgrade ptr.is\_aligned\_to crate\-private*

### (nominated) rust.tf/122661 *Assert that the first \`assert!\` expression is \`bool\`*

### (nominated) rust.tf/123110 *Rename iter::Iterator::intersperse() to ::separate()*

### (nominated) rust.tf/123168 *Add \`size\_of\` and \`size\_of\_val\` and \`align\_of\` and \`align\_of\_val\` to the prelude*

### (waiting on team) rust.tf/119550 *Rename \`AsyncIterator\` back to \`Stream\`, introduce an AFIT\-based \`AsyncIterator\` trait*

### (new change proposal) rust.tf/libs363 *Un\-specialize impl ToString*

### (new change proposal) rust.tf/libs364 *ACP: Add {Box, Rc, Arc}::map and {Box, Rc, Arc}::try\_map*

### (new change proposal) rust.tf/libs365 *ACP: \`TwoSidedRange\` trait*

### (new change proposal) rust.tf/libs366 *Implementing UnixSocketExt traits for solaris/illumos ; starting with the unix\_socket\_exclbind feature*

### (new change proposal) rust.tf/libs367 *Enable accessing written data in a \`BorrowedCursor\`*

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

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

### (stalled change proposal) rust.tf/libs215 *Implement AsRef, Borrow for std::cell::Ref, RefMut*

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

### (stalled change proposal) rust.tf/libs211 *Windows MSVC CRT linking*