This will be a big breaking change, but I'm actually struggling more than I thought I would to make improvements as things stand.

I think the following changes will help:

• Make Solution generic over Part as well as Day, i.e. Solution<Day, Part>
• Move input parsing into the Solution trait
  • this means each Part knows how to parse its own input, which could simplify things
  • I'm not sure yet how this would affect sharing the parsed input between Parts when possible

The default run method will parse the input twice.

This is ~twice as slow in the common case of using the same parsed input for both parts of a day. This feels like a trap and I consider it a bug.

There is an example in the docs of overriding it to share the parsed input like this:

let shared_parsed_input = <Self as ParseInput<Day1>>::parse_input(input);
let part1_output = Self::part1(&shared_parsed_input);
let part2_output = Self::part2(&shared_parsed_input);

Could the default implementation be changed to do this where possible, and fall back to parsing input twice when needed? i.e. when ParseEachInput is implemented with different types of Parsed.

This might be impossible, in which case I'd appreciate suggestions of other ideas.

Currently, running a day using a struct that implements more than one day requires Fully Qualified Syntax which is a bit on the verbose side and can be confusing:

<AdventOfCode2020 as Solution<Day1>>::run(&input);

I am considering creating a function style proc_macro that would turn the below into the the above when compiled:

run!(&input, Day1, AdventOfCode2020);

I'm open to suggestions on the exact syntax.

I think this should be included under a default feature (if possible)

Massive breaking change, will release as 0.2.

This fixes 2 of the biggest gripes I had with the original version:

• running your solution needed ugly fully qualified syntax
• by default you would parse input twice when running the solution, even if both parts used the same input type

This fixes both of them using autoderef specialization in stable rust.

I've also removed a couple of examples as sharing/splitting parsing between parts is so much more intuitive now.

I also realised that the cli and boilerplate examples overlapped significantly, it just makes sense in hindsight to have one good example for now.

If you use this library to do Advent of Code for any year, I'd love to hear your thoughts on the experience.

I'd also like to link to external repositories with solutions using these traits or any other creative uses of them.

All the methods on the traits so far are associated functions.

So essentially the implementing struct is just a marker or container for organising the solutions. It has no use for any data or fields.

I'd like people to experiment with this idea, I have in mind fun implementations of Solution like this:

// from Advent of Code 2019
pub struct IntcodeComputer {
    program: Vec<Instruction>,
    stack: Vec<i32>,
    register: HashMap<Register, i32>,
}

impl Solution<Day2> for IntcodeComputer {
    fn part1(&self) -> u32 {
        // use the intcode computer and access its fields, methods!
        self.program.iter() // ...
    }
}

We could even have mutability.

impl Solution<Day2> for IntcodeComputer {
    fn part1(&mut self) -> u32 {
        // use the intcode computer and mutate it while solving the solution
       self.stack.push(3)
    }
}

Currently this is done inline in the run method.

// TODO: extract printing behaviour into a report or summary method with a default implementation
println!(
    "Day {0}, Part 1\n\
    {1}\n\n\
    Day {0}, Part 1\n\
    {2}",
    Day, part1_output, part2_output
);

I can foresee plenty of reasons to want to customise this and I'd like to enable that more easily.

Separating into two methods means the user can do that without having to re-implement the running of part1 and part2 which is a bit more involved..

Currently none of the trait methods contain Result in their type signature, so ? won't work in their implementations.

This encourages a lot of unwrap/expect where I would rather discourage it.

I initially avoided using Result in the trait methods because I want to display the output, so I required Display. However Result doesn't implement Display. I think this might be solvable with a more complicated trait bound combining both Result and Display.

Also, that then forces everyone to return a Result in their implementations, that might be a good thing though since this library aims to be used by beginners to Rust.

This would be a breaking change so the sooner the better!