rely less on macros

[remi-dupre]

This makes the tool easier to maintain and extend for the future. Also, the future of GATs might allow some flexibility.

[rbtcollins]

Asked to comment here from my PR fixing borrowed data in returned iterators.

Ultimately, this crate and aoc-runner/'cargo aoc' are just conveniences. When folk are doing the competitive side of AOC, Rust is probably the wrong choice for most if not all puzzles - countless one-liners in numpy for instance are faster to create because of the super high level capabilities there.

What I and some others I know do is just do it in Rust for fun. For the lols. And there we end up playing code golf and seeing how fast we can get some algorithms. Last year I had some down to 300ns - and the generator was 4us - 10x slower than the actual runner.

In that scenario there was nothing borrowed, but sometimes it is convenient to just return a generator straight from stack where no allocations take place, and then for that being able to
a) borrow the input and return a struct with borrowed refers from the generator and
b) borrow the input passed to the runner to process it (with a cheap clone since the whole struct is a handful of words)

... is super convenient.

It was in fact one of the things that brought me to aoc-main vs 'cargo aoc'.

The other thing I'd love is a better way to manage many-year collections of aoc puzzles. Right now I use branches, because both aoc-main and aoc-runner want to both own the entry point, but not provide a year multiplexer.

[remi-dupre]

I solved this borrow issue by leaking the input (which means we can borrow it statically and we don't have to pass along values that look like Box<for<'i> Fn(.. + 'i) -> .. + 'i), this is not very elegant but I think doing consistently better requires some GAT thingies that have not been stabilized yet.

Now that I have a working core I'll still try to iterate on it, trying to make something more elegant.