import { DateTime } from './DateAdapter';
import { IRecurrenceRule, IRecurrenceRulesIterator } from './recurrence-rule';
import { INormRuleOptionsBase } from './recurrence-rule-options';
export interface IRecurrenceRulesIteratorArgs {
  start?: DateTime;
  end?: DateTime;
  reverse?: boolean;
}
export interface IRunNextArgs {
  /**
   * Moves the iterator state forward so that it is equal
   * to or past the given date. The provided date *must*
   * be greater than the last yielded date (or, when iterating
   * in reverse, it must be smaller). This is more efficent then  repeatedly
   * iterating and throwing away values until the desired date
   * is reached.
   */
  skipToDate?: DateTime;
}
export declare class RecurrenceRulesIterator<T extends INormRuleOptionsBase>
  implements
    IRecurrenceRulesIterator<T>,
    Iterator<DateTime, undefined, IRunNextArgs | undefined> {
  readonly options: T;
  readonly start: DateTime;
  readonly end?: DateTime;
  readonly reverse: boolean;
  readonly isInfinite: boolean;
  readonly hasDuration: boolean;
  protected readonly args: IRecurrenceRulesIteratorArgs;
  protected readonly rules: IRecurrenceRule[];
  protected iterator: Generator<DateTime, undefined, IRunNextArgs | undefined>;
  /**
   * In the pipe controller, we have an extra level of indirection with
   * the `run()` and `iterate()` methods. The `iterate()` method is the
   * method which actually runs the logic in the pipes. If we didn't
   * need to account for the `count` property of a rule, we would *only*
   * need the iterate method... so much simpler. But we do need to account
   * for rules with a `count` property.
   *
   * Rules with a `count` property need to begin iteration at the beginning
   * because the `count` is always from the rule's start time. So if someone
   * passes in a new start time as an argument to a rule with `count`, we
   * need to secretly iterate from the beginning, tracking the number of
   * iterations, and then only start yielding dates when we reach the section
   * the user cares about (or, if we hit our `count` quota, cancel iterating).
   *
   * Additionally, we need to handle iterating in reverse. In this case, we build
   * up a cache of dates between the rule's start time and the reverse iteration
   * start date. Once we hit the reverse iteration start date, we start
   * yielding dates in the cache, in reverse order.
   *
   * In general, I imagine the count number, if used, will be small. But a large
   * count will definitely have a negative performance affect. I don't think
   * there's anything to be done about this.
   */
  private iterateWithReverseCount;
  private iterateWithCount;
  private iterate;
  /**
   * Loops through the recurrence rules until a valid date is found.
   */
  private nextDate;
  /**
   * Performs one run of the recurrence rules and returns the result.
   * It's a slightly optimized reducer function.
   */
  private runRules;
  private isDatePastEnd;
  private normalizeRunOutput;
  private normalizeDateTimeArgs;
  constructor(
    recurrenceRules:
      | IRecurrenceRule[]
      | ((iterator: IRecurrenceRulesIterator<T>) => IRecurrenceRule[]),
    options: T,
    args: IRecurrenceRulesIteratorArgs,
  );
  [Symbol.iterator](): Generator<DateTime, undefined, IRunNextArgs | undefined>;
  next(args?: IRunNextArgs): IteratorResult<DateTime, undefined>;
}