pub trait VectorFn<T> {
// Required methods
fn len(&self) -> usize;
fn at(&self, i: usize) -> T;
// Provided methods
fn is_empty(&self) -> bool { ... }
fn into_iter(self) -> VectorFnIter<Self, T> ⓘ
where Self: Sized { ... }
fn iter(&self) -> VectorFnIter<&Self, T> ⓘ { ... }
fn map_fn<F: Fn(T) -> U, U>(self, func: F) -> VectorFnMap<Self, T, U, F>
where Self: Sized { ... }
fn step_by_fn(self, step_by: usize) -> StepByFn<Self, T>
where Self: Sized { ... }
}Expand description
A trait for objects that provides random-position access to a 1-dimensional sequence (or vector) of elements that returned by value.
§Related traits
Other traits that represent sequences are
ExactSizeIterator: Also returns elements by value; However, to avoid copying elements, anExactSizeIteratorreturns every item only once, and only in the order of the underlying vector.VectorView: Returns only references to the underlying data, but also supports random-position access. Note thatVectorView<T>is not the same asVectorFn<&T>, since the lifetime of returned references&Tin the case ofVectorViewis the lifetime of the vector, but in the case ofVectorFn, it must be a fixed lifetime parameter.
Finally, there is the subtrait SelfSubvectorFn, which directly supports taking subvectors.
§Example
fn compute_sum<V: VectorFn<usize>>(vec: V) -> usize {
let mut result = 0;
for i in 0..vec.len() {
result += vec.at(i);
}
return result;
}
assert_eq!(10, compute_sum(1..5));
assert_eq!(10, compute_sum([1, 2, 3, 4].copy_els()));
assert_eq!(10, compute_sum(vec![1, 2, 3, 4].copy_els()));
assert_eq!(10, compute_sum((&[1, 2, 3, 4, 5][..4]).copy_els()));Required Methods§
Provided Methods§
fn is_empty(&self) -> bool
Sourcefn into_iter(self) -> VectorFnIter<Self, T> ⓘwhere
Self: Sized,
fn into_iter(self) -> VectorFnIter<Self, T> ⓘwhere
Self: Sized,
Produces an iterator over the elements of this VectorFn.
This transfers ownership of the object to the iterator. If this
is not desired, consider using VectorFn::iter().
Note that VectorFns do not necessarily implement IntoIterator and
instead use this function. The reason for that is twofold:
- the only way of making all types implementing
VectorFns to also implementIntoIteratorwould be to defineVectorFnas a subtrait ofIntoIterator. However, this conflicts with the decision to haveVectorFnhave the element type as generic parameter, sinceIntoIteratoruses an associated type. - If the above problem could somehow be circumvented, for types that implement both
IteratorandVectorFn(likeRange), callinginto_iter()would then require fully-qualified call syntax, which is very unwieldy.
Sourcefn iter(&self) -> VectorFnIter<&Self, T> ⓘ
fn iter(&self) -> VectorFnIter<&Self, T> ⓘ
Produces an iterator over the elements of this VectorFn.
See also VectorFn::into_iter() if a transfer of ownership is required.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".
Implementations on Foreign Types§
Source§impl VectorFn<usize> for Range<usize>
§Why no impl for Range<i64> etc?
It is a common pattern to write (0..n).map_fn(|x| ...) to create general
VectorFns. If we provide impls for multiple Ranges, then in this
case however, explicit type arguments will be necessary. Instead, if you
require a VectorFn over another numerical type T, consider using
((start as usize)..(end as usize)).map_fn(|x| x as T).
impl VectorFn<usize> for Range<usize>
§Why no impl for Range<i64> etc?
It is a common pattern to write (0..n).map_fn(|x| ...) to create general
VectorFns. If we provide impls for multiple Ranges, then in this
case however, explicit type arguments will be necessary. Instead, if you
require a VectorFn over another numerical type T, consider using
((start as usize)..(end as usize)).map_fn(|x| x as T).