Closed clarfonthey closed 11 months ago
Namely, on the current edition,
<Box<[T]>>::into_iter
would call the<&[T]>::into_iter
definition instead, and only on future editions would it call<Box<[T]>>::into_iter
.
For arrays, the edition hack was only about what array.into_iter()
resolved to. We did not make different behavior for more direct use of <[T; N] as IntoIterator>::into_iter
. This is documented here:
https://doc.rust-lang.org/std/primitive.array.html#editions
Ahh, I didn't actually know those specifics about the edition hack. I'm honestly not even sure if a hack would be required in this case, but I figured I would make an ACP and talk about it since I remembered that being a contentious issue at the time. Maybe a crater run would just show that I'm being overly cautious.
It definitely is an analogous situation, that boxed_slice.into_iter()
will currently auto-deref to a slice iterator. Maybe crater will reveal that this is uncommon, but it was definitely an issue with arrays.
Also, I just remembered that I tried this before and failed due to Iterator for Box<I>
: https://github.com/rust-lang/rust/issues/59878#issuecomment-808965376
@cuviper Negative impls can now make this possible by impl<T> !Iterator for [T]
, like we impl !Error for &str
.
We discussed this in the libs-api meeting. We're happy with this change since it is clearer the "more correct" behavior for Box<[T]>::into_iter
.
This should be tried with a crater run first. If breaking changes are too significant then a workaround could be prepared for the 2024 edition (it's not yet clear what this would involve, it depends on the crater results).
Proposal
Problem statement
Right now, calling
<Box<[T]>>::into_iter
has the same issue that<[T; N]>::into_iter
had prior to Rust edition 2021: it takes the box by reference instead of by value, since it implicitly refers to the implementation of<&[T]>::into_iter
.However, this can be done by-value by converting the
Box
to aVec
first, returningvec::IntoIter
instead.Motivating examples or use cases
Boxed slices can be used in many of the same places as
Vec
s, and they have much of the same use cases, which means they should have the same behaviour.Solution sketch
IntoIterator
forBox<[T]>
would be implemented, providing the following definition:However, this would likely require per-edition inference like the exception made for
IntoIterator for [T; N]
, only properly working on an edition bump. Namely, on the current edition,<Box<[T]>>::into_iter
would call the<&[T]>::into_iter
definition instead, and only on future editions would it call<Box<[T]>>::into_iter
. Older-edition code would have to callinto_vec().into_iter()
instead.Alternatives
The main alternative is to do nothing, since the possible alternative is only slightly longer.
(Old edition example):
(New edition example):
Links and related work
None known.
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution: