sragu.rs

1. this:
  if a.is_none() || c == std::u64::MAX {
      None
  } else {
      a.unwrap().checked_add(c)
  }
can be replaces with (not sure if it compiles though...):   
  a.and_then(|value| value.checked_add(c))
    
2. Once you start using Option for something in your code, you have to use Option everywhere, otherwise composition looks horrible.
  But I don't really get iterators. I think you can do this(this definetly won't compile):

impl Iterator for PeasantTables {
    type Item = Entry;
    fn next(&mut self) -> Option<Entry> {
        // Can we make an assumption that self.next will give you an Option<Entry> ?
        // is it possible?
        let current: Option<Entry> = Entry { ..self.next };
        
        // the composition would look like this. As you can see, it is hard to read:  
      
        let result = current.and_then(|entry| entry.first.checked_mul(2).
                                and_then(|first| entry.second.checked_div(2)).
                                  map(|second| Entry {first: first, second: second}))
                                  
        // if only RUST had list comprehansions the above code would look like this:
        
        let result = for {
          entry  <- current
          first  <- entry.first.checked_mul(2)
          second <- entry.second.checked_div(2)
        } yield Entry {first: first, second: second}
        
        // but even though you can make it readable with pattern matching which should work in Rust:
        
        let result = current.and_then{|entry|
          match (entry.first.checked_mul(2), entry.second.checked_div(2)) {
            (Some(first), Some(second)) => Entry {first: first, second: second}
            _                         => None
          }
        }
        
        self.next = result
        result
    }
}

using option all the way down to datastructures looks weird, bcos I expect not to create an entry with either invalid first/second. thats why using option all the way is kinda sad 👎

Iterators are kinda for just generator for sequences, like ranges. But pure generators makes state management easier.

List comprehensions are more readable as you said, just have to wait until it lands in rust.

I also quite liked how javascript/swift let you to name the anonymous closures, that way it makes bit more readable where needed.

In rust I could not easily extract a closure like
x.reject(|x| x.second %2 == 0)
into
let evenValues = |x| x.second %2 == 0; x.reject(evenValues)

nono @sragu, you shouldn't have Option of i64, that would be wrong for the reasons you just said: entry with either invalid first/second is invalid state. What I mean is that once you decide to use Option, it has to be an Option for self.next as well.