Мені здається, що поки .step_by
метод не стане стабільним, можна легко виконати те, що ви хочете, за допомогою Iterator
(що Range
насправді є тим, що насправді є):
struct SimpleStepRange(isize, isize, isize);
impl Iterator for SimpleStepRange {
type Item = isize;
#[inline]
fn next(&mut self) -> Option<isize> {
if self.0 < self.1 {
let v = self.0;
self.0 = v + self.2;
Some(v)
} else {
None
}
}
}
fn main() {
for i in SimpleStepRange(0, 10, 2) {
println!("{}", i);
}
}
Якщо потрібно повторити декілька діапазонів різних типів, код можна зробити загальним таким чином:
use std::ops::Add;
struct StepRange<T>(T, T, T)
where for<'a> &'a T: Add<&'a T, Output = T>,
T: PartialOrd,
T: Clone;
impl<T> Iterator for StepRange<T>
where for<'a> &'a T: Add<&'a T, Output = T>,
T: PartialOrd,
T: Clone
{
type Item = T;
#[inline]
fn next(&mut self) -> Option<T> {
if self.0 < self.1 {
let v = self.0.clone();
self.0 = &v + &self.2;
Some(v)
} else {
None
}
}
}
fn main() {
for i in StepRange(0u64, 10u64, 2u64) {
println!("{}", i);
}
}
Я залишаю вам усунути перевірку верхніх меж, щоб створити відкриту структуру, якщо потрібен нескінченний цикл ...
Переваги цього підходу в тому, що він працює з for
шугарінгом і буде продовжувати працювати навіть тоді, коли нестабільні функції стануть придатними для використання; також, на відміну від підходу Range
, що не зацукрований, що використовує стандартні s, він не втрачає ефективності від кількох .next()
дзвінків. Недоліками є те, що для налаштування ітератора потрібно кілька рядків коду, тому це може коштувати лише для коду, який має багато циклів.