koenichiwa

Quick thought, why don't you implement ScheduleFields like: ```rust impl ScheduleFields { pub(crate) fn new( seconds: Seconds, minutes: Minutes, hours: Hours, days_of_month: DaysOfMonth, months: Months, days_of_week: DaysOfWeek, years: Years, )...

I tried to make a draft, but it seems I was mistaken. The nom parser seems to filter the values somewhere(?) I'm not sure how it really works.

Yeah sure! I'm not really at home with licensing though, so if you can do that, then I can work on the other two issues?

Quick question about `OrdinalIter` `OrdinalRangeIter` etc. Shouldn't they actually reside in the ordinal module? Edit: I was also looking into making them just type definitions like so: ```rust pub type...

Welp, I guess your right. The execution time changed from 186 to 184, which is insignificant, and it was a pain to code with. I have a counter offer though,...

> It leaks implementation details to users of the crate. At least at the time, error messages would contain the aliased type names (Cloned It prevented me from having control...

On an unrelated note, I have two nits. - `OrdinalRangeIter` does not implement `Iter`, shouldn't it get renamed to `OrdinalRange` - `ScheduleIterator` is returned by some public functions of `Schedule`....

> think I've missed a beat: what's the use case for users creating their own ordinal iterators? Oh no, I meant exactly the opposite! If I refactor it out to...

Nothing to worry about. My study picked up the pace again, so I'm focusing on other stuff currently. We'll get back to this later 🙂

Having said that. I was bored, and thought I would implement ordinal.rs back to the struct/impl implementation. I left the type aliases commented though, so you can make a comparison,...