For the last two years, I've blogged my approaches to the Advent of Code puzzles on my personal site. Assuming I hold true to form, each blog post will include code and commentary on my thinking behind the approach, my thoughts about the puzzles, and vain attempts at wit.
This year, I'm using Rust! I solved 2019's puzzles in Rust after the fact (it's how I learned Rust to begin with), but this year I'll solve each day in Rust first. I've set up folders for each day's code and input files like so:
<project root>
├─benches
│ └─all_days.rs
├─input
│ └─XX
│ ├─input.txt
│ └─test.txt
├─src
│ ├─dayXX
│ │ ├─input.rs
│ │ ├─mod.rs
│ │ ├─part1.rs
│ │ └─part2.rs
│ ├─bin.rs
│ └─lib.rs
├─Cargo.toml
└─README.md
There are a few organizational notes to point out here:
-
The
mod.rs
file for each day definesInput
as a type alias for the type the input file will be parsed into, and a convenience functionrun(_: Part) -> Output
that reads in the input and solves for either part one or part two, depending on the variant ofPart
that is passed and returns the result as an Output (for consistency). This file also contains the tests that cofirm the answer once it has been found. -
Output
is an enum with variants foru32
,i32
,u64,
i64, and
String`. This allows the binary to expect the same (printable) type from each day's solution. -
Input files are being included in each day's
input.rs
via theinclude_str!()
macro, which means parsing will be on the file contents as one long, newline-separated, string slice. The main entrypoint for input parsing is theread() -> Input
function which takes no arguments (relying on the includedINPUT
constant) and returns the parsed input file. -
The
part1.rs
andpart2.rs
files each contain asolve(_: &Input) -> Output
function that takes a reference to the parsed input and returns the solution for that part of that day.Most of the functionality of this project shell is best accessed via
cargo
(though you can install the project if you really want to).