Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
use super ::TrustedLen ;
2020-09-18 09:51:26 +02:00
/// Conversion from an [`Iterator`].
2018-12-17 17:29:39 -05:00
///
/// By implementing `FromIterator` for a type, you define how it will be
/// created from an iterator. This is common for types which describe a
/// collection of some kind.
///
2022-03-03 19:45:53 -05:00
/// If you want to create a collection from the contents of an iterator, the
2022-03-04 09:48:51 -05:00
/// [`Iterator::collect()`] method is preferred. However, when you need to
/// specify the container type, [`FromIterator::from_iter()`] can be more
/// readable than using a turbofish (e.g. `::<Vec<_>>()`). See the
2022-03-03 19:45:53 -05:00
/// [`Iterator::collect()`] documentation for more examples of its use.
2018-12-17 17:29:39 -05:00
///
/// See also: [`IntoIterator`].
///
/// # Examples
///
/// Basic usage:
///
/// ```
/// let five_fives = std::iter::repeat(5).take(5);
///
/// let v = Vec::from_iter(five_fives);
///
/// assert_eq!(v, vec![5, 5, 5, 5, 5]);
/// ```
///
2020-09-18 09:51:26 +02:00
/// Using [`Iterator::collect()`] to implicitly use `FromIterator`:
2018-12-17 17:29:39 -05:00
///
/// ```
/// let five_fives = std::iter::repeat(5).take(5);
///
/// let v: Vec<i32> = five_fives.collect();
///
/// assert_eq!(v, vec![5, 5, 5, 5, 5]);
/// ```
///
2022-03-03 19:45:53 -05:00
/// Using [`FromIterator::from_iter()`] as a more readable alternative to
/// [`Iterator::collect()`]:
///
/// ```
2022-03-04 09:45:18 -05:00
/// use std::collections::VecDeque;
2022-03-03 19:45:53 -05:00
/// let first = (0..10).collect::<VecDeque<i32>>();
/// let second = VecDeque::from_iter(0..10);
///
/// assert_eq!(first, second);
/// ```
///
2018-12-17 17:29:39 -05:00
/// Implementing `FromIterator` for your type:
///
/// ```
/// // A sample collection, that's just a wrapper over Vec<T>
/// #[derive(Debug)]
/// struct MyCollection(Vec<i32>);
///
/// // Let's give it some methods so we can create one and add things
/// // to it.
/// impl MyCollection {
/// fn new() -> MyCollection {
/// MyCollection(Vec::new())
/// }
///
/// fn add(&mut self, elem: i32) {
/// self.0.push(elem);
/// }
/// }
///
/// // and we'll implement FromIterator
/// impl FromIterator<i32> for MyCollection {
/// fn from_iter<I: IntoIterator<Item=i32>>(iter: I) -> Self {
/// let mut c = MyCollection::new();
///
/// for i in iter {
/// c.add(i);
/// }
///
/// c
/// }
/// }
///
/// // Now we can make a new iterator...
/// let iter = (0..5).into_iter();
///
/// // ... and make a MyCollection out of it
/// let c = MyCollection::from_iter(iter);
///
/// assert_eq!(c.0, vec![0, 1, 2, 3, 4]);
///
/// // collect works too!
///
/// let iter = (0..5).into_iter();
/// let c: MyCollection = iter.collect();
///
/// assert_eq!(c.0, vec![0, 1, 2, 3, 4]);
/// ```
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
#[ rustc_on_unimplemented(
2023-05-15 21:08:45 +03:00
on (
_Self = " &[{A}] " ,
message = " a slice of type `{Self}` cannot be built since we need to store the elements somewhere " ,
label = " try explicitly collecting into a `Vec<{A}>` " ,
) ,
on (
all ( A = " {integer} " , any ( _Self = " &[{integral}] " , ) ) ,
message = " a slice of type `{Self}` cannot be built since we need to store the elements somewhere " ,
label = " try explicitly collecting into a `Vec<{A}>` " ,
) ,
2021-12-01 18:51:27 -08:00
on (
_Self = " [{A}] " ,
2022-04-26 21:09:26 -07:00
message = " a slice of type `{Self}` cannot be built since `{Self}` has no definite size " ,
2021-12-01 18:51:27 -08:00
label = " try explicitly collecting into a `Vec<{A}>` " ,
) ,
on (
2022-04-26 21:09:26 -07:00
all ( A = " {integer} " , any ( _Self = " [{integral}] " , ) ) ,
message = " a slice of type `{Self}` cannot be built since `{Self}` has no definite size " ,
2021-12-01 18:51:27 -08:00
label = " try explicitly collecting into a `Vec<{A}>` " ,
) ,
2022-04-26 21:09:26 -07:00
on (
_Self = " [{A}; _] " ,
message = " an array of type `{Self}` cannot be built directly from an iterator " ,
label = " try collecting into a `Vec<{A}>`, then using `.try_into()` " ,
) ,
on (
all ( A = " {integer} " , any ( _Self = " [{integral}; _] " , ) ) ,
message = " an array of type `{Self}` cannot be built directly from an iterator " ,
label = " try collecting into a `Vec<{A}>`, then using `.try_into()` " ,
) ,
2019-12-06 20:18:12 -08:00
message = " a value of type `{Self}` cannot be built from an iterator \
over elements of type ` { A } ` " ,
label = " value of type `{Self}` cannot be built from `std::iter::Iterator<Item={A}>` "
2018-12-17 17:29:39 -05:00
) ]
2021-07-06 13:41:22 +00:00
#[ rustc_diagnostic_item = " FromIterator " ]
2018-12-17 17:29:39 -05:00
pub trait FromIterator < A > : Sized {
/// Creates a value from an iterator.
///
/// See the [module-level documentation] for more.
///
2020-10-12 13:42:49 -07:00
/// [module-level documentation]: crate::iter
2018-12-17 17:29:39 -05:00
///
/// # Examples
///
/// ```
/// let five_fives = std::iter::repeat(5).take(5);
///
/// let v = Vec::from_iter(five_fives);
///
/// assert_eq!(v, vec![5, 5, 5, 5, 5]);
/// ```
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
2023-09-26 23:56:38 -04:00
#[ rustc_diagnostic_item = " from_iter_fn " ]
2019-12-06 20:18:12 -08:00
fn from_iter < T : IntoIterator < Item = A > > ( iter : T ) -> Self ;
2018-12-17 17:29:39 -05:00
}
2024-04-03 17:48:54 +00:00
/// This implementation turns an iterator of tuples into a tuple of types which implement
/// [`Default`] and [`Extend`].
///
/// This is similar to [`Iterator::unzip`], but is also composable with other [`FromIterator`]
/// implementations:
///
/// ```rust
/// # fn main() -> Result<(), core::num::ParseIntError> {
/// let string = "1,2,123,4";
///
/// let (numbers, lengths): (Vec<_>, Vec<_>) = string
/// .split(',')
/// .map(|s| s.parse().map(|n: u32| (n, s.len())))
/// .collect::<Result<_, _>>()?;
///
/// assert_eq!(numbers, [1, 2, 123, 4]);
/// assert_eq!(lengths, [1, 1, 3, 1]);
/// # Ok(()) }
/// ```
2024-04-28 09:28:27 -04:00
#[ stable(feature = " from_iterator_for_tuple " , since = " 1.79.0 " ) ]
2023-01-30 08:56:37 +00:00
impl < A , B , AE , BE > FromIterator < ( AE , BE ) > for ( A , B )
where
A : Default + Extend < AE > ,
B : Default + Extend < BE > ,
{
fn from_iter < I : IntoIterator < Item = ( AE , BE ) > > ( iter : I ) -> Self {
let mut res = < ( A , B ) > ::default ( ) ;
res . extend ( iter ) ;
res
}
}
2020-09-18 09:51:26 +02:00
/// Conversion into an [`Iterator`].
2018-12-17 17:29:39 -05:00
///
/// By implementing `IntoIterator` for a type, you define how it will be
/// converted to an iterator. This is common for types which describe a
/// collection of some kind.
///
/// One benefit of implementing `IntoIterator` is that your type will [work
2020-10-12 13:42:49 -07:00
/// with Rust's `for` loop syntax](crate::iter#for-loops-and-intoiterator).
2018-12-17 17:29:39 -05:00
///
/// See also: [`FromIterator`].
///
/// # Examples
///
/// Basic usage:
///
/// ```
2021-12-17 18:36:18 +11:00
/// let v = [1, 2, 3];
2018-12-17 17:29:39 -05:00
/// let mut iter = v.into_iter();
///
/// assert_eq!(Some(1), iter.next());
/// assert_eq!(Some(2), iter.next());
/// assert_eq!(Some(3), iter.next());
/// assert_eq!(None, iter.next());
/// ```
/// Implementing `IntoIterator` for your type:
///
/// ```
/// // A sample collection, that's just a wrapper over Vec<T>
/// #[derive(Debug)]
/// struct MyCollection(Vec<i32>);
///
/// // Let's give it some methods so we can create one and add things
/// // to it.
/// impl MyCollection {
/// fn new() -> MyCollection {
/// MyCollection(Vec::new())
/// }
///
/// fn add(&mut self, elem: i32) {
/// self.0.push(elem);
/// }
/// }
///
/// // and we'll implement IntoIterator
/// impl IntoIterator for MyCollection {
/// type Item = i32;
2019-10-20 21:13:47 +03:00
/// type IntoIter = std::vec::IntoIter<Self::Item>;
2018-12-17 17:29:39 -05:00
///
/// fn into_iter(self) -> Self::IntoIter {
/// self.0.into_iter()
/// }
/// }
///
/// // Now we can make a new collection...
/// let mut c = MyCollection::new();
///
/// // ... add some stuff to it ...
/// c.add(0);
/// c.add(1);
/// c.add(2);
///
/// // ... and then turn it into an Iterator:
/// for (i, n) in c.into_iter().enumerate() {
/// assert_eq!(i as i32, n);
/// }
/// ```
///
/// It is common to use `IntoIterator` as a trait bound. This allows
/// the input collection type to change, so long as it is still an
/// iterator. Additional bounds can be specified by restricting on
/// `Item`:
///
/// ```rust
/// fn collect_as_strings<T>(collection: T) -> Vec<String>
2019-07-31 21:00:35 +02:00
/// where
2019-08-09 13:40:54 +02:00
/// T: IntoIterator,
/// T::Item: std::fmt::Debug,
2018-12-17 17:29:39 -05:00
/// {
/// collection
/// .into_iter()
2022-02-12 23:16:17 +04:00
/// .map(|item| format!("{item:?}"))
2018-12-17 17:29:39 -05:00
/// .collect()
/// }
/// ```
2019-11-01 12:04:18 +01:00
#[ rustc_diagnostic_item = " IntoIterator " ]
Use root obligation on E0277 for some cases
When encountering trait bound errors that satisfy some heuristics that
tell us that the relevant trait for the user comes from the root
obligation and not the current obligation, we use the root predicate for
the main message.
This allows to talk about "X doesn't implement Pattern<'_>" over the
most specific case that just happened to fail, like "char doesn't
implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`
The heuristics are:
- the type of the leaf predicate is (roughly) the same as the type
from the root predicate, as a proxy for "we care about the root"
- the leaf trait and the root trait are different, so as to avoid
talking about `&mut T: Trait` and instead remain talking about
`T: Trait` instead
- the root trait is not `Unsize`, as to avoid talking about it in
`tests/ui/coercion/coerce-issue-49593-box-never.rs`.
```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
--> $DIR/root-obligation.rs:6:38
|
LL | .filter(|c| "aeiou".contains(c))
| -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
| |
| required by a bound introduced by this call
|
= note: required for `&char` to implement `FnOnce<(char,)>`
= note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
--> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
|
LL | .filter(|c| "aeiou".contains(*c))
| +
```
Fix #79359, fix #119983, fix #118779, cc #118415 (the suggestion needs
to change).
2024-02-29 00:35:59 +00:00
#[ rustc_on_unimplemented(
on (
_Self = " core::ops::range::RangeTo<Idx> " ,
label = " if you meant to iterate until a value, add a starting value " ,
note = " `..end` is a `RangeTo`, which cannot be iterated on; you might have meant to have a \
bounded ` Range ` : ` 0 .. end ` "
) ,
on (
_Self = " core::ops::range::RangeToInclusive<Idx> " ,
label = " if you meant to iterate until a value (including it), add a starting value " ,
note = " `..=end` is a `RangeToInclusive`, which cannot be iterated on; you might have meant \
to have a bounded ` RangeInclusive ` : ` 0 ..= end ` "
) ,
on (
_Self = " [] " ,
label = " `{Self}` is not an iterator; try calling `.into_iter()` or `.iter()` "
) ,
on ( _Self = " &[] " , label = " `{Self}` is not an iterator; try calling `.iter()` " ) ,
on (
_Self = " alloc::vec::Vec<T, A> " ,
label = " `{Self}` is not an iterator; try calling `.into_iter()` or `.iter()` "
) ,
on (
_Self = " &str " ,
label = " `{Self}` is not an iterator; try calling `.chars()` or `.bytes()` "
) ,
on (
_Self = " alloc::string::String " ,
label = " `{Self}` is not an iterator; try calling `.chars()` or `.bytes()` "
) ,
on (
_Self = " {integral} " ,
note = " if you want to iterate between `start` until a value `end`, use the exclusive range \
syntax ` start .. end ` or the inclusive range syntax ` start ..= end ` "
) ,
on (
_Self = " {float} " ,
note = " if you want to iterate between `start` until a value `end`, use the exclusive range \
syntax ` start .. end ` or the inclusive range syntax ` start ..= end ` "
) ,
label = " `{Self}` is not an iterator " ,
message = " `{Self}` is not an iterator "
) ]
2024-06-11 15:08:34 +02:00
#[ rustc_skip_during_method_dispatch(array, boxed_slice) ]
2018-12-17 17:29:39 -05:00
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
pub trait IntoIterator {
/// The type of the elements being iterated over.
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
type Item ;
/// Which kind of iterator are we turning this into?
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
2019-12-06 20:18:12 -08:00
type IntoIter : Iterator < Item = Self ::Item > ;
2018-12-17 17:29:39 -05:00
/// Creates an iterator from a value.
///
/// See the [module-level documentation] for more.
///
2020-10-12 13:42:49 -07:00
/// [module-level documentation]: crate::iter
2018-12-17 17:29:39 -05:00
///
/// # Examples
///
/// ```
2021-12-17 18:36:18 +11:00
/// let v = [1, 2, 3];
2018-12-17 17:29:39 -05:00
/// let mut iter = v.into_iter();
///
/// assert_eq!(Some(1), iter.next());
/// assert_eq!(Some(2), iter.next());
/// assert_eq!(Some(3), iter.next());
/// assert_eq!(None, iter.next());
/// ```
2020-08-26 10:17:31 +02:00
#[ lang = " into_iter " ]
2018-12-17 17:29:39 -05:00
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
fn into_iter ( self ) -> Self ::IntoIter ;
}
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
2023-04-16 06:49:27 +00:00
impl < I : Iterator > IntoIterator for I {
2018-12-17 17:29:39 -05:00
type Item = I ::Item ;
type IntoIter = I ;
2021-04-25 21:18:42 +02:00
#[ inline ]
2018-12-17 17:29:39 -05:00
fn into_iter ( self ) -> I {
self
}
}
/// Extend a collection with the contents of an iterator.
///
/// Iterators produce a series of values, and collections can also be thought
/// of as a series of values. The `Extend` trait bridges this gap, allowing you
/// to extend a collection by including the contents of that iterator. When
/// extending a collection with an already existing key, that entry is updated
/// or, in the case of collections that permit multiple entries with equal
/// keys, that entry is inserted.
///
/// # Examples
///
/// Basic usage:
///
/// ```
/// // You can extend a String with some chars:
/// let mut message = String::from("The first three letters are: ");
///
/// message.extend(&['a', 'b', 'c']);
///
/// assert_eq!("abc", &message[29..32]);
/// ```
///
/// Implementing `Extend`:
///
/// ```
/// // A sample collection, that's just a wrapper over Vec<T>
/// #[derive(Debug)]
/// struct MyCollection(Vec<i32>);
///
/// // Let's give it some methods so we can create one and add things
/// // to it.
/// impl MyCollection {
/// fn new() -> MyCollection {
/// MyCollection(Vec::new())
/// }
///
/// fn add(&mut self, elem: i32) {
/// self.0.push(elem);
/// }
/// }
///
/// // since MyCollection has a list of i32s, we implement Extend for i32
/// impl Extend<i32> for MyCollection {
///
/// // This is a bit simpler with the concrete type signature: we can call
/// // extend on anything which can be turned into an Iterator which gives
/// // us i32s. Because we need i32s to put into MyCollection.
/// fn extend<T: IntoIterator<Item=i32>>(&mut self, iter: T) {
///
/// // The implementation is very straightforward: loop through the
/// // iterator, and add() each element to ourselves.
/// for elem in iter {
/// self.add(elem);
/// }
/// }
/// }
///
/// let mut c = MyCollection::new();
///
/// c.add(5);
/// c.add(6);
/// c.add(7);
///
/// // let's extend our collection with three more numbers
/// c.extend(vec![1, 2, 3]);
///
/// // we've added these elements onto the end
2022-02-12 23:16:17 +04:00
/// assert_eq!("MyCollection([5, 6, 7, 1, 2, 3])", format!("{c:?}"));
2018-12-17 17:29:39 -05:00
/// ```
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
pub trait Extend < A > {
/// Extends a collection with the contents of an iterator.
///
2020-05-12 20:09:55 -07:00
/// As this is the only required method for this trait, the [trait-level] docs
2018-12-17 17:29:39 -05:00
/// contain more details.
///
2020-09-18 09:51:26 +02:00
/// [trait-level]: Extend
2018-12-17 17:29:39 -05:00
///
/// # Examples
///
/// ```
/// // You can extend a String with some chars:
/// let mut message = String::from("abc");
///
/// message.extend(['d', 'e', 'f'].iter());
///
/// assert_eq!("abcdef", &message);
/// ```
#[ stable(feature = " rust1 " , since = " 1.0.0 " ) ]
2019-12-06 20:18:12 -08:00
fn extend < T : IntoIterator < Item = A > > ( & mut self , iter : T ) ;
2020-05-12 20:09:55 -07:00
/// Extends a collection with exactly one element.
2020-05-26 14:15:29 -07:00
#[ unstable(feature = " extend_one " , issue = " 72631 " ) ]
2020-05-12 20:09:55 -07:00
fn extend_one ( & mut self , item : A ) {
self . extend ( Some ( item ) ) ;
}
/// Reserves capacity in a collection for the given number of additional elements.
///
/// The default implementation does nothing.
2020-05-26 14:15:29 -07:00
#[ unstable(feature = " extend_one " , issue = " 72631 " ) ]
2020-05-26 14:01:26 -07:00
fn extend_reserve ( & mut self , additional : usize ) {
let _ = additional ;
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
/// Extends a collection with one element, without checking there is enough capacity for it.
///
/// # Safety
///
/// **For callers:** This must only be called when we know the collection has enough capacity
/// to contain the new item, for example because we previously called `extend_reserve`.
///
/// **For implementors:** For a collection to unsafely rely on this method's safety precondition (that is,
/// invoke UB if they are violated), it must implement `extend_reserve` correctly. In other words,
/// callers may assume that if they `extend_reserve`ed enough space they can call this method.
// This method is for internal usage only. It is only on the trait because of specialization's limitations.
#[ unstable(feature = " extend_one_unchecked " , issue = " none " ) ]
#[ doc(hidden) ]
unsafe fn extend_one_unchecked ( & mut self , item : A )
where
Self : Sized ,
{
self . extend_one ( item ) ;
}
2018-12-17 17:29:39 -05:00
}
#[ stable(feature = " extend_for_unit " , since = " 1.28.0 " ) ]
impl Extend < ( ) > for ( ) {
fn extend < T : IntoIterator < Item = ( ) > > ( & mut self , iter : T ) {
iter . into_iter ( ) . for_each ( drop )
}
2020-05-12 20:09:55 -07:00
fn extend_one ( & mut self , _item : ( ) ) { }
2018-12-17 17:29:39 -05:00
}
2021-05-30 18:44:37 +02:00
2024-10-26 17:25:10 +02:00
macro_rules ! spec_tuple_impl {
( ( $ty_name :ident , $var_name :ident , $extend_ty_name : ident , $trait_name :ident , $default_fn_name :ident , $cnt :tt ) , ) = > {
2024-10-26 18:58:05 +02:00
spec_tuple_impl! ( $trait_name , $default_fn_name , #[ doc(fake_variadic) ] #[ doc = " This trait is implemented for tuples up to twelve items long. The `impl`s for 1- and 3- through 12-ary tuples were stabilized after 2-tuples, in RUSTC_CURRENT_VERSION. " ] = > ( $ty_name , $var_name , $extend_ty_name , $cnt ) , ) ;
2024-10-26 17:25:10 +02:00
} ;
( ( $ty_name :ident , $var_name :ident , $extend_ty_name : ident , $trait_name :ident , $default_fn_name :ident , $cnt :tt ) , $( ( $ty_names :ident , $var_names :ident , $extend_ty_names :ident , $trait_names :ident , $default_fn_names :ident , $cnts :tt ) , ) * ) = > {
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
spec_tuple_impl! ( $( ( $ty_names , $var_names , $extend_ty_names , $trait_names , $default_fn_names , $cnts ) , ) * ) ;
2024-10-26 18:58:05 +02:00
spec_tuple_impl! ( $trait_name , $default_fn_name , #[ doc(hidden) ] = > ( $ty_name , $var_name , $extend_ty_name , $cnt ) , $( ( $ty_names , $var_names , $extend_ty_names , $cnts ) , ) * ) ;
2024-10-26 17:25:10 +02:00
} ;
2024-10-26 18:58:05 +02:00
( $trait_name :ident , $default_fn_name :ident , #[ $meta:meta ] $( #[ $doctext:meta ] ) ? = > $( ( $ty_names :ident , $var_names :ident , $extend_ty_names :ident , $cnts :tt ) , ) * ) = > {
#[ $meta ]
$( #[ $doctext ] ) ?
#[ stable(feature = " extend_for_tuple " , since = " 1.56.0 " ) ]
2024-10-26 17:25:10 +02:00
impl < $( $ty_names , ) * $( $extend_ty_names , ) * > Extend < ( $( $ty_names , ) * ) > for ( $( $extend_ty_names , ) * )
where
$( $extend_ty_names : Extend < $ty_names > , ) *
{
/// Allows to `extend` a tuple of collections that also implement `Extend`.
///
/// See also: [`Iterator::unzip`]
///
/// # Examples
/// ```
/// // Example given for a 2-tuple, but 1- through 12-tuples are supported
/// let mut tuple = (vec![0], vec![1]);
/// tuple.extend([(2, 3), (4, 5), (6, 7)]);
/// assert_eq!(tuple.0, [0, 2, 4, 6]);
/// assert_eq!(tuple.1, [1, 3, 5, 7]);
///
/// // also allows for arbitrarily nested tuples as elements
/// let mut nested_tuple = (vec![1], (vec![2], vec![3]));
/// nested_tuple.extend([(4, (5, 6)), (7, (8, 9))]);
///
/// let (a, (b, c)) = nested_tuple;
/// assert_eq!(a, [1, 4, 7]);
/// assert_eq!(b, [2, 5, 8]);
/// assert_eq!(c, [3, 6, 9]);
/// ```
fn extend < T : IntoIterator < Item = ( $( $ty_names , ) * ) > > ( & mut self , into_iter : T ) {
let ( $( $var_names , ) * ) = self ;
let iter = into_iter . into_iter ( ) ;
$trait_name ::extend ( iter , $( $var_names , ) * ) ;
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
fn extend_one ( & mut self , item : ( $( $ty_names , ) * ) ) {
$( self . $cnts . extend_one ( item . $cnts ) ; ) *
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
fn extend_reserve ( & mut self , additional : usize ) {
$( self . $cnts . extend_reserve ( additional ) ; ) *
}
unsafe fn extend_one_unchecked ( & mut self , item : ( $( $ty_names , ) * ) ) {
// SAFETY: Those are our safety preconditions, and we correctly forward `extend_reserve`.
unsafe {
$( self . $cnts . extend_one_unchecked ( item . $cnts ) ; ) *
}
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
}
2024-10-26 17:25:10 +02:00
trait $trait_name < $( $ty_names ) , * > {
fn extend ( self , $( $var_names : & mut $ty_names , ) * ) ;
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
fn $default_fn_name < $( $ty_names , ) * $( $extend_ty_names , ) * > (
iter : impl Iterator < Item = ( $( $ty_names , ) * ) > ,
$( $var_names : & mut $extend_ty_names , ) *
) where
$( $extend_ty_names : Extend < $ty_names > , ) *
{
fn extend < ' a , $( $ty_names , ) * > (
$( $var_names : & ' a mut impl Extend < $ty_names > , ) *
) -> impl FnMut ( ( ) , ( $( $ty_names , ) * ) ) + ' a {
#[ allow(non_snake_case) ]
move | ( ) , ( $( $extend_ty_names , ) * ) | {
$( $var_names . extend_one ( $extend_ty_names ) ; ) *
}
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
let ( lower_bound , _ ) = iter . size_hint ( ) ;
if lower_bound > 0 {
$( $var_names . extend_reserve ( lower_bound ) ; ) *
}
2021-05-30 18:44:37 +02:00
2024-10-26 17:25:10 +02:00
iter . fold ( ( ) , extend ( $( $var_names , ) * ) ) ;
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
impl < $( $ty_names , ) * $( $extend_ty_names , ) * Iter > $trait_name < $( $extend_ty_names ) , * > for Iter
where
$( $extend_ty_names : Extend < $ty_names > , ) *
Iter : Iterator < Item = ( $( $ty_names , ) * ) > ,
{
default fn extend ( self , $( $var_names : & mut $extend_ty_names ) , * ) {
$default_fn_name ( self , $( $var_names ) , * ) ;
2021-05-30 18:44:37 +02:00
}
}
2024-10-26 17:25:10 +02:00
impl < $( $ty_names , ) * $( $extend_ty_names , ) * Iter > $trait_name < $( $extend_ty_names ) , * > for Iter
where
$( $extend_ty_names : Extend < $ty_names > , ) *
Iter : TrustedLen < Item = ( $( $ty_names , ) * ) > ,
{
fn extend ( self , $( $var_names : & mut $extend_ty_names , ) * ) {
fn extend < ' a , $( $ty_names , ) * > (
$( $var_names : & ' a mut impl Extend < $ty_names > , ) *
) -> impl FnMut ( ( ) , ( $( $ty_names , ) * ) ) + ' a {
#[ allow(non_snake_case) ]
// SAFETY: We reserve enough space for the `size_hint`, and the iterator is `TrustedLen`
// so its `size_hint` is exact.
move | ( ) , ( $( $extend_ty_names , ) * ) | unsafe {
$( $var_names . extend_one_unchecked ( $extend_ty_names ) ; ) *
}
}
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
let ( lower_bound , upper_bound ) = self . size_hint ( ) ;
Specialize `TrustedLen` for `Iterator::unzip()`
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
2024-07-07 06:58:52 +03:00
2024-10-26 17:25:10 +02:00
if upper_bound . is_none ( ) {
// We cannot reserve more than `usize::MAX` items, and this is likely to go out of memory anyway.
$default_fn_name ( self , $( $var_names , ) * ) ;
return ;
}
2021-05-30 18:44:37 +02:00
2024-10-26 17:25:10 +02:00
if lower_bound > 0 {
$( $var_names . extend_reserve ( lower_bound ) ; ) *
}
self . fold ( ( ) , extend ( $( $var_names , ) * ) ) ;
}
2021-05-30 18:44:37 +02:00
}
2024-10-26 17:25:10 +02:00
} ;
2021-05-30 18:44:37 +02:00
}
2024-10-26 17:25:10 +02:00
spec_tuple_impl! (
( L , l , EL , TraitL , default_extend_tuple_l , 11 ) ,
( K , k , EK , TraitK , default_extend_tuple_k , 10 ) ,
( J , j , EJ , TraitJ , default_extend_tuple_j , 9 ) ,
( I , i , EI , TraitI , default_extend_tuple_i , 8 ) ,
( H , h , EH , TraitH , default_extend_tuple_h , 7 ) ,
( G , g , EG , TraitG , default_extend_tuple_g , 6 ) ,
( F , f , EF , TraitF , default_extend_tuple_f , 5 ) ,
( E , e , EE , TraitE , default_extend_tuple_e , 4 ) ,
( D , d , ED , TraitD , default_extend_tuple_d , 3 ) ,
( C , c , EC , TraitC , default_extend_tuple_c , 2 ) ,
( B , b , EB , TraitB , default_extend_tuple_b , 1 ) ,
( A , a , EA , TraitA , default_extend_tuple_a , 0 ) ,
) ;