midwitsanonymous

Day 2:

The MidWit — Fri, 05 Jun 2026 00:00:00 GMT

Note

You can find the text of the puzzle here.

Overview

The basic aim here is to take in a series of parcel dimensions (stored as strings of numbers separated by “x”) and use them to calculate the total amount of wrapping paper (part 1) and ribbon for bows (part 2).

Concepts

using my own modules (including the aoc_common code from SideQuest 1)
closures (getting totals)
parsing Strings to i32
returning from main (like I know what that means).

Limitations - Modules and Functions and tests (Oh My!)

As my aim isn’t to just solve the problems, but to work towards a polished solution and so I’m going to try to write as little code in main.rs as possible, and to start everything with tests (burgh).

Set up

# I'm working on NixOs
# move into my root
$ cd aoc
# create a new folder with cargo
$ cargo new day_2
// -- snip -- just output showing the project getting made
# create the parcel.rs file
$ touch day_2/src/parcel.rs

So that gives us most of what we need in the way of set up, but the last things I need to do are:

add my aoc_common code as a dependency in day_2/Cargo.toml¹

[package]
name = "day_2"
version = "0.1.0"
edition = "2024"

[dependencies]
aoc_common = {path = "../aoc_common"} # this line

add day_2 to the workspace toml file

[workspace]
members = [
  "aoc_common",
  "day_2",
  ]

Part 1

Formulae

This puzzle is about wrapping presents (which I’m calling parcels from here on out), and to get enough paper (in this economy?!) there are a few things we need to do:

Calculate its surface area
2 * (length * width) + 2 * (length * height) + 2 * (width * height)
Calculate the area of the smallest face
- find the smallest side first
- edge_1 * edge_2
Add the two products together

And finally we need to get the result of combining all those calculations.

Rolls up sleeves: Let’s kick this pig

Parcel `Struct`

Ok, so I’m going to try to put everything into a Parcel Struct inside parcel.rs and as per my TDD goal I’m going to start with a test.

`test_new()`

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_new() {
        assert_eq!(
                Parcel { 
                    l : 1,
                    w : 2,
                    h : 3,
                },
                Parcel::new(1,2,3)
            );
        }

    }

And we have our first test. It just lets me test a new() associated method. It also contains the code to define the Struct, I just need to yank it up into a definition and set the field types.

Implement `new()`

// define the struct
#[derive(Debug, PartialEq)] //deriving needed traits
pub struct Parcel { // pub from the get go this time!
            l : i32,
            w : i32,
            h : i32,
        }

impl Parcel { // implement the `new()` function
    pub fn new(l:i32, w: i32, h:i32) -> Parcel {
        Parcel { l, w, h }
    }
}

    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.21s
     Running unittests src/main.rs (/home/sp1d3r-z3r0/MyProjects-tmp/midwitsanonymous/scratch/target/debug/deps/day_2-f26cfbed71fb1d31)

running 1 test
test parcel::tests::test_new ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

There it is; the first Boom! It’s not, like, earth-shaking because this isn’t exactly rocket surgery and I was pretty sure this would work. But, I’m not one to pass up a “boom” when I see one.

Makin’ calculations

We know from earlier that we have a few different calculations we need to perform to come up with our final answer. Rather than working my way in from the whole Parcel I’m going to work out from the area of the smallest side first.

`test_smallest_area()`

Let’s write the test

    #[test]
    fn test_smallest_area() {
        // make a new parce
        let test_parcel = Parcel::new(1,2,3);
        assert_eq!(test_parcel.smallest_area(), 2
            );
    }

And add it to our implementation

Perfectly fine Catastrophic `smallest_area()`

// -- snip -- 
    pub fn smallest_area(&self) -> i32 {
        let s1 = self.l * self.w;
        let s2 = self.l * self.h;
        let s3 = self.w * self.h;
        let smallest = {
            if s1 <= s2 & s1 <= s3 {
                s1
            } else if s2 <= s1 & s2 <= s3 {
                s2
            } else {
                s3
            }
        };
        smallest
    }

And there we have it, a perfectly fine implementation of the smallest_area() function. Yes indeedy!… Nothing wrong with this… probably could skip the test… but you know what, let’s just run it, for the look of the thing.

  --> day_2/src/parcel.rs:19:19
   |
19 |             if s1 <= s2 & s1 <= s3 {
   |                   ^^         ^^
   |
help: split the comparison into two
   |
19 |             if s1 <= s2 & s1 && s2 & s1 <= s3 {
   |                              ++++++++++

error: comparison operators cannot be chained
  --> day_2/src/parcel.rs:21:26
   |
21 |             } else if s2 <= s1 & s2 <= s3 {
   |                          ^^         ^^
   |
help: split the comparison into two
   |
21 |             } else if s2 <= s1 & s2 && s1 & s2 <= s3 {
   |                                     ++++++++++

error[E0308]: mismatched types
  --> day_2/src/parcel.rs:19:33
   |
19 |             if s1 <= s2 & s1 <= s3 {
   |                -------------    ^^ expected `bool`, found `i32`
   |                |
   |                expected because this is `bool`

error[E0308]: mismatched types
  --> day_2/src/parcel.rs:21:40
   |
21 |             } else if s2 <= s1 & s2 <= s3 {
   |                       -------------    ^^ expected `bool`, found `i32`
   |                       |
   |                       expected because this is `bool`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `day_2` (bin "day_2" test) due to 4 previous errors

Well… That’s fine

Oh, the hubris! Like Daedalus before me, certain of another Boom. Yet instead, I find myself the perpetrator of a (say it with me folks) Rust Rookie Mistake!

Again, Friend Computer is benevolent, showing me how to fix the error, but it’s worth taking a second for me to really mark that. To the documenatrium!!.

And and And

`&`

According to the docs the & symbol, as well as indicating a ‘borrow’ represents the “Bitwise AND” of two objects. Now I def’ine’itly ain’t the person to explain this but as I understand it ², this performs the “AND” operations on the binary representation of 2 objects.

So let’s imagine that we have 2 sets of 4 bits

column	1	2	3	4
row a	0	0	1	1
row b	0	1	1	0

Reading down the columns we compare the 2 values:

If they’re both 1s -> we get 1
If they’re both 0s -> we get 0
If they’re different values -> 0

So with the table above we’d get the value

column	2	3	4
row a	0	1	1
row b	1	1	0
result	0	1	0

Great, that’s a good thing for me to have learned… (I guess… kicks dust)

`&&`

As Friend Computer said up in our last Socratic dialogue, what I was really looking for was the “Short-circuiting logical AND” which allows us to combine multiple boolean conditions so that both must be true in order to move forward.

Which is what I naively thought I was doing above… in the before times. The Halcyon days if you will.

But why does this matter?³

Believe it or not, this is actually the first time I’ve encountered the coding equivalent of ‘PEMDAS’⁴. Again, I don’t know the ins-and-outs of it but essentially the ‘Bitwise’ & is higher in the hierarchy of operations than the comparison operators so where I thought I was writing

if x <= y and x <= z

I was actually writing

if x <= (y and x) <= z

Meaning the (x and y) happens first, which creates two further problems here (I think):

x <= (x and y) produces a bool while z is an i32: we can’t compare those types
unlike python, Rust doesn’t let us chain comparison operators like that…

And all because I wanted to compare some numbers! Like a sweet summer child.

So… (cough) let’s do that

Fixing `smallest_area()`

// -- snip --
        let smallest = {
            if s1 <= s2 && s1 <= s3 {
                s1
            } else if s2 <= s1 && s2 <= s3 {
                s2
            } else {
                s3
            }
// -- snip --

Breathe deeply and let’s test it

running 2 tests
test parcel::tests::test_new ... ok
test parcel::tests::test_smallest_area ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

And there’s the second BOOM!

The function calculates the areas of all three sides and then gives us back that value as an i32 that we can use in the next function.

`wrapping_paper()`

I want one function that can just hand us back the amount of wrapping paper needed. This means that it should use the smallest_area() function as part of the calculations on a given Parcel instance.

As always, our first step is to write a test for our wrapping_paper() function

`test_wrapping()`

// -- snip --
    #[test]
    fn test_wrapping_paper() {
        // make a new parce
        let test_parcel = Parcel::new(1,2,3);
        assert_eq!(test_parcel.wrapping_paper(), 24
            );
    }
// -- snip --

implementing `wrapping_paper()`


// -- snip --
    pub fn wrapping_paper(&self) -> i32 {
        {
            2 * (self.l * self.w) 
          + 2 * (self.l * self.h) 
          + 2 * (self.w * self.h)
          + self.smallest_area()
        }
    }
// -- snip --

In the past, in my youth of two function definitions ago, I would have faced this next cargo test confidently.

Pridefully.

But now, oh now, I just trust Friend Computer to give me guidance and to look upon my errors with grace.

running 3 tests
test parcel::tests::test_new ... ok
test parcel::tests::test_wrapping_paper ... ok
test parcel::tests::test_smallest_area ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

BOOM! I am a genius! I Always knew it! (cough, wheeze, push up glasses)

I mean… good. Boom.

So we have the functions to get the results we need for Part 1, and yet there’s something else I want to do before we pipe all this into main.

`from_string()`

Warning

Dear Reader, while the following passages are an accurate portrayal of Sisyphean struggle, this next section is long and dense with error output. It does show some truly top class “MidWittery” but if you want to just skip to the part where it gets solved… then go to How I was wrong.. But you’ll miss the stunning interpersonal drama!!

As we covered in SideQuest 1 I’m storing all the puzzle input in ./input.txt, and I wrote the aoc_common module to help reading it in. The input for this puzzle is in the format:

9x13x26
11x11x14
27x2x5
6x10x13
15x19x10
26x29x15
// -- snip --

Which will get pulled as:

"9x13x26\n
11x11x14\n
27x2x5\n
6x10x13\n
15x19x10\n
26x29x15\n
// -- snip -- 
8x23x6\n"

Or one long string separated by newlines. from_string() is intended to take in an individual line of that text, trim the newline, split on the 'x' char and create a new Parcel from the 3 i32s.

Test first; ask questions later

Test `from_string()`

    #[test]
    fn from_string() {
        // make a new parce
        assert_eq!(
            Parcel::new(1,2,3),
            Parcel::from_string(String::from("1x2x3\n"))
            );
    }

Then onto implementing the function

First attempt

    pub fn from_string(dimensions: &str) -> Parcel {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>())
                               .collect::<Vec<i32>>();
        Parcel::new({numbers[0], numbers[1], numbers[2])
    }

Here’s the first shot at it.

We’re turning the input text (taking a &str because I believe it’s more flexible) and turning it into a vector of i32 numbers using the map iterator adaptor with a .parse() inside a closure.

Then, we use the . syntax to pass each of those numbers into our Parcel::new() associated function from earlier which gives us a Parcel we can return out of the function⁵.

Let’s see if this works?

error[E0277]: a value of type `Vec<i32>` cannot be built from an iterator over elements of type `Result<i32, ParseIntError>`
  --> day_2/src/parcel.rs:23:43
   |
23 | ...                   .collect::<Vec<i32>>();
   |                        -------   ^^^^^^^^ value of type `Vec<i32>` cannot be built from `std::iter::Iterator<Item=Result<i32
, ParseIntError>>`
   |                        |
   |                        required by a bound introduced by this call
   |
help: the trait `FromIterator<Result<i32, ParseIntError>>` is not implemented for `Vec<i32>`
      but trait `FromIterator<i32>` is implemented for it
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/alloc/src/vec/mod.rs:3862:0
   = help: for that trait implementation, expected `i32`, found `Result<i32, ParseIntError>`
note: the method call chain might not have had the expected associated types
  --> day_2/src/parcel.rs:22:33
   |
18 |        let numbers: Vec<i32> = dimensions
   |                                ---------- this expression has type `&str`
19 |                                .trim_end()
20 |                                .split("x")
   |                                 ---------- `Iterator::Item` is `&str` here
21 |                                .into_iter()
   |                                 ----------- `Iterator::Item` remains `&str` here
22 |                                .map(|n| n.parse::<i32>())
   |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^ `Iterator::Item` changed to `Result<i32, ParseIntError>` here
note: required by a bound in `collect`
  --> /rustc/59807616e1fa254error[E0308]: mismatched types
  --> day_2/src/parcel.rs:89:33
   |
89 |             Parcel::from_string(String::from("1x2x3\n"))
   |             ------------------- ^^^^^^^^^^^^^^^^^^^^^^^ expected `&str`, found `String`
   |             |
   |             arguments to this function are incorrect
   |
note: associated function defined here
  --> day_2/src/parcel.rs:16:12
   |
16 |     pub fn from_string(dimensions: &str) -> Parcel {
   |            ^^^^^^^^^^^ ----------------
help: consider borrowing here
   |
89 |             Parcel::from_string(&String::from("1x2x3\n"))
   |                                 +

Some errors have detailed explanations: E0277, E0308.0724bfbac14d7976d7e4a3860/library/core/src/iter/traits/iterator.rs:2051:4

Bo–…

Ok, so jokes aside, this feels a really good learning error here. Let’s look at it from top to bottom and let me see if I understand what’s going on and what the fixes are telling me. There’s basically the same error here, just twice and in two different places.

We can’t make a Vec from the map(|n| n.parse::())
Parcel::from_string() is expecting a &str but in the test I’ve passed it an owned String. (Flexible my ass…)

As always MidWit, you look but you do not observe!

`map` -> `Result`

Believe it or not, this first error is a blessing, especially following on from SideQuest 1.

So what we’re being told here, which I did akshully know, was that map isn’t just giving me back i32s here. It’s giving me back the outcome of calling parse::() on each element in the collection that split("x") gives me.

Result

You guys all saw this, but this is our second RRM⁶ of the puzzle.

If I understand this right: the parse method can fail, like a lot of things in rust, and so when we use map to call that on each object in a collection, we can’t be certain that all of the objects are amenable to being parsed. Like, what if the string was “1x2xbannanana\n”? I’d look like a fool then wouldn’t I?

So map gives us back Results that we need to handle just as we would anywhere else. This means that I could use unwrap() or expect() to make the function panic and stop the program if one of the given values wasn’t… parcable?… parcible?… numeric. However, given that the aim here is to reach to what I believe are good practices, maybe this gives us access to the ? operator, and to returning a Result?

Nothin’ to it but to do it.

Second attempt: trying `?`

use core::{iter::IntoIterator, num::ParseIntError}; // nvim/my lsp added these for me
// -- snip --
    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>())
                               .collect::<Vec<Ok(i32)>>()?; //changed the return type and added?
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2])) // returing an Ok(Parcel) now
    }

// -- snip --
// updating the test
    #[test]
    fn from_string() {
        // make a new parce
        assert_eq!(
            Parcel::new(1,2,3),
            Parcel::from_string("1x2x3\n").unwrap()
            );
    }

Lot of changes up there, but in brief:

My editor gave me some use statements to bring some things that I’d need into scope. Thanks Obama.
I’ve changed the return types in a few places to put Result or its variants everywhere.
I’ve updated the test to reflect this (I was clearly wrong about the flexibility of slices).

Now, I’m 90% sure that I’ve got the wrong turbofish on the collect() and that the ? operator is in the wrong place, but we’re here to learn so let’s FISI and see what we get.

Note

Dear Reader, he did in fact have the wrong turbofish.

He did not, in fact, have the ? in the wrong place.

error[E0573]: expected type, found variant `Ok`
  --> day_2/src/parcel.rs:23:47
   |
23 | ...                   .collect::<Vec<Ok(i32)>>()?;
   |                                      ^^^^^^^ not a type
   |
help: try using the variant's enum
   |
23 -                                .collect::>()?;
23 +                                .collect::>()?;
   |
23 -                                .collect::>()?;
23 +                                .collect::>()?;
   |

For more information about this error, try `rustc --explain E0573`.
error: could not compile `day_2` (bin "day_2" test) due to 1 previous error

Ok, I was Schrodinger’s correct again!

Note

No, in fact the cat was just dead.

The turbofish needs the Result and not the variant. However the ? doesn’t seem to be throwing me an error… so The MidWit Strikes again!!

// -- snip -- 
    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>())
                               .collect::<Vec<Result<i32, ParseIntError>>>()?;
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2]))
    }

error[E0277]: the `?` operator can only be applied to values that implement `Try`
  --> day_2/src/parcel.rs:18:32
   |
18 |          let numbers: Vec<i32> = dimensions
   |  ________________________________^
19 | |                                .trim_end()
20 | |                                .split("x")
21 | |                                .into_iter()
22 | |                                .map(|n| n.parse::<i32>())
23 | |                                .collect::<Vec<Result<i32, ParseIntError>>>()?;
   | |_____________________________________________________________________________^ the `?` operator cannot be applied to type `
Vec<Result<i32, ParseIntError>>`
   |
   = help: the nightly-only, unstable trait `Try` is not implemented for `Vec<Result<i32, ParseIntError>>`

There it is!! Turns out I was entirely right; I did get it completely wrong!! The ? is also wrong. I knew it! I am a genius!

Note

He’s now multiple steps deep in the wrong.

Honestly, my hope here is that this is telling me that the ? needs to either go on the parse or on the map. Imma try both, and then… I’ll ask Claude if this is even possible.

I’m not going to put two more big blocks of code in there just to show that I’ve moved one symbol around. So map(..)? first.

// --snip --
error[E0277]: the `?` operator can only be applied to values that implement `Try`
  --> day_2/src/parcel.rs:18:32
   |
18 |          let numbers: Vec<i32> = dimensions
   |  ________________________________^
19 | |                                .trim_end()
20 | |                                .split("x")
21 | |                                .into_iter()
22 | |                                .map(|n| n.parse::<i32>())?
   | |__________________________________________________________^ the `?` operator cannot be applied to type `Map<std::str::Split
<'_, &str>, {closure@day_2/src/parcel.rs:22:37: 22:40}>`
// -- snip --

Same error, so map(|n| n.parse::()?) next.

error[E0277]: the `?` operator can only be used in a closure that returns `Result` or `Option` (or another type that implements `
FromResidual`)
  --> day_2/src/parcel.rs:22:57
   |
22 | ...                   .map(|n| n.parse::<i32>()?)
   |                            ---                 ^ cannot use the `?` operator in a closure that returns `i32`
   |                            |
   |                            this function should return `Result` or `Option` to accept `?`

error[E0277]: a value of type `Vec<Result<i32, ParseIntError>>` cannot be built from an iterator over elements of type `i32`
  --> day_2/src/parcel.rs:23:43
   |
23 | ...                   .collect::<Vec<Result<i32, ParseIntError>>>();
   |                        -------   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value of type `Vec<Result<i32, ParseIntError>>` cannot be b
uilt from `std::iter::Iterator<Item=i32>`
   |                        |
   |                        required by a bound introduced by this call
   |
help: the trait `FromIterator<i32>` is not implemented for `Vec<Result<i32, ParseIntError>>`
      but trait `FromIterator<Result<i32, ParseIntError>>` is implemented for it
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/alloc/src/vec/mod.rs:3862:0
   = help: for that trait implementation, expected `Result<i32, ParseIntError>`, found `i32`
note: the method call chain might not have had the expected associated types
  --> day_2/src/parcel.rs:22:33
   |
18 |        let numbers: Vec<i32> = dimensions
   |                                ---------- this expression has type `&str`
19 |                                .trim_end()
20 |                                .split("x")
   |                                 ---------- `Iterator::Item` is `&str` here
21 |                                .into_iter()
   |                                 ----------- `Iterator::Item` remains `&str` here
22 |                                .map(|n| n.parse::<i32>()?)
   |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^ `Iterator::Item` changed to `i32` here
note: required by a bound in `collect`
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/iter/traits/iterator.rs:2051:4
error[E0308]: mismatched types
  --> day_2/src/parcel.rs:18:32
   |
18 |          let numbers: Vec<i32> = dimensions
   |  _____________________--------___^
   | |                     |
   | |                     expected due to this
19 | |                                .trim_end()
20 | |                                .split("x")
21 | |                                .into_iter()
22 | |                                .map(|n| n.parse::<i32>()?)
23 | |                                .collect::<Vec<Result<i32, ParseIntError>>>();
   | |____________________________________________________________________________^ expected `Vec<i32>`, found `Vec<Result<i32, ParseIntError>>`
   |
   = note: expected struct `Vec<i32>`
              found struct `Vec<Result<i32, ParseIntError>>`_

Huh… That’s… a lot…

What we got here… Is a failure… to communicate.

That move changed a lot more than I expected. Either I missed something in earlier output, or adding the ? operator directly to the parse is handling the Result for me…

Note

He did, in fact, miss something earlier.

Ok, I know I said I’d ask Claude if I couldn’t figure it out, but just gimme a sec here.

// -- snip -- 
    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>()?)
                               .collect::<Vec<i32>>(); // note that we've gone back to Vec here
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2]))
    }

error[E0277]: the `?` operator can only be used in a closure that returns `Result` or `Option` (or another type that implements `
FromResidual`)
  --> day_2/src/parcel.rs:22:57
   |
22 | ...                   .map(|n| n.parse::<i32>()?)
   |                            ---                 ^ cannot use the `?` operator in a closure that returns `i32`
   |                            |
   |                            this function should return `Result` or `Option` to accept `?`

For more information about this error, try `rustc --explain E0277`.

Well… crap.

I thought I was onto something there. But as they say, faint hearts never won fair maiden so I’m going to try something a bit less ergonomic but that might help this click for me.

Getting Explicit: Dropping `?`

// -- snip --
    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| {
                                   let num = n.parse::<i32>();
                                   let d = match num {
                                        Ok(i) => i,
                                        Err(_e) => {
                                            println!("You didn't get a number fool");
                                            0
                                        }
                                   };
                                   d
                               }
                                )
                               .collect::<Vec<i32>>();
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2]))
    }
// -- snip --

That’s… ugly code… and I’m pretty sure that the return type is wrong

running 4 tests
test parcel::tests::from_string ... ok
test parcel::tests::test_new ... ok
test parcel::tests::test_smallest_area ... ok
test parcel::tests::test_wrapping_paper ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00

But, explicitly handling the error lets the test pass… ~~great~~.

Right! Time to stop stumbling around.

Note

Hang on, Dear Reader. This is nearly over, and there’s a shocking betrayal coming up!!

What do I think I know?

You definitely already know where I’m going wrong, but I’m not seeing it.

Based on how I’m understanding the various error messages, the main problem here is my misunderstanding what types are getting produced at each step, and therefore where ? might be relevant. Friend Computer gives good feedback, but it’s ephemeral, it doesn’t know what has been tried previously or what misconceptions I have.

If I’m trying to learn-by-doing here it would probably be a good idea to reset and try to think through where I’m at.

So what am I assuming here?

split is giving me back a Split object which is a collection in itself (caveats aside).
map takes that collection, lets me run some function over it giving me back a collection (after .collect()).
- map will also give me an error if it encounters something the internal function can’t work on.
parse() gives me a Result
collect() gives me back the collection.
the ? operator can only be called on something that produces a Result or Option…

Which reminds me of something else.

calling next on a collection can return an Option with Some(T) when there is a thing at that position in the collection.
However, if there’s nothing at that position, say if we’ve reached the end of the array, it can give us None.

So, maybe instead of Vec> in the .collect() turbofish (which just seemed wrong anyway) maybe it should be a Vec>.

Trying `Option`

    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>()?)
                               .collect::<Vec<Option<i32>>>();
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2]))
    }

error[E0277]: the `?` operator can only be used in a closure that returns `Result` or `Option` (or another type that implements `
FromResidual`)
  --> day_2/src/parcel.rs:22:57
   |
22 | ...                   .map(|n| n.parse::<i32>()?)
   |                            ---                 ^ cannot use the `?` operator in a closure that returns `i32`
   |                            |
   |                            this function should return `Result` or `Option` to accept `?`

error[E0277]: a value of type `Vec<Option<i32>>` cannot be built from an iterator over elements of type `i32`
  --> day_2/src/parcel.rs:23:43
   |
23 | ...                   .collect::<Vec<Option<i32>>>();
   |                        -------   ^^^^^^^^^^^^^^^^ value of type `Vec<Option<i32>>` cannot be built from `std::iter::Iterator
<Item=i32>`
   |                        |
   |                        required by a bound introduced by this call
   |
help: the trait `FromIterator<i32>` is not implemented for `Vec<Option<i32>>`
      but trait `FromIterator<Option<i32>>` is implemented for it
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/alloc/src/vec/mod.rs:3862:0
   = help: for that trait implementation, expected `Option<i32>`, found `i32`
note: the method call chain might not have had the expected associated types
  --> day_2/src/parcel.rs:22:33
   |
18 |        let numbers: Vec<i32> = dimensions
   |                                ---------- this expression has type `&str`
19 |                                .trim_end()
20 |                                .split("x")
   |                                 ---------- `Iterator::Item` is `&str` here
21 |                                .into_iter()
   |                                 ----------- `Iterator::Item` remains `&str` here
22 |                                .map(|n| n.parse::<i32>()?)
   |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^ `Iterator::Item` changed to `i32` here
note: required by a bound in `collect`
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/iter/traits/iterator.rs:2051:4

error[E0308]: mismatched types
  --> day_2/src/parcel.rs:18:32
   |
18 |          let numbers: Vec<i32> = dimensions
   |  _____________________--------___^
   | |                     |
   | |                     expected due to this
19 | |                                .trim_end()
20 | |                                .split("x")
21 | |                                .into_iter()
22 | |                                .map(|n| n.parse::<i32>()?)
23 | |                                .collect::<Vec<Option<i32>>>();
   | |_____________________________________________________________^ expected `Vec<i32>`, found `Vec<Option<i32>>`
   |
   = note: expected struct Vec<i32>

Sigh…

Getting “help”

Ok, so… that’s very similar to an earlier error and we both know that this ain’t an interesting read…

Note

See? He’s not oblivious.

He keeps missing that he’s typehinting result as Vec, but he’s not completely oblivious.

Here comes the betrayal. Don’t look away, but hold your loved ones close.

I have a passing solution, I just don’t like it. Rather than staying nerdsniped though, I’m going to ask Claude if the idea is actually possible. I’m going to pass what I’ve written in with the prompt along with the question

My question

Here’s what I’ve written so far, and ,I’ve also tried just dropping the ? entirly and turbofishing both a vec and a Vec> and both failed. So I’m not understanding something about this order. The compiler tells me that the map is returning a result and that indicates to me that I should be able to write this more ergonomically than I have in the passing version, maybe that’s an if let rather than ? Just tell me, with no editorialising or additional guidance, can I use ? in this context?

Claude’s answer

Yes — but not the way you’ve been placing it, and not on the closure inside map. The ? goes on the collect, not inside the map. And the single thing that makes it work, which you haven’t tried, is the turbofish: you have to collect into Result, ParseIntError> — the Result on the outside, Vec inside — not Vec>. Once the collect produces a single Result, ? has something it can be applied to. Your two collect attempts both failed because Vec can’t be built from Result items, and Vec> is a vector, which ? can’t touch. The shape you never tried is the one that works.

Welp! That sucks.

Note

Et tu Brute?!

You can’t see this Dear Reader, but he’s livid.

I’m going to… set aside the fact that Claude just robbed me of figuring this out on my own by completely ignoring

“Just tell me, with no editorialising or additional guidance[…]”

and handing me the answer⁷. But to be clear I’m really annoyed.

Note

The raw human suffering is hard to read.

How I was wrong.

Anyway, I think I see what’s happening here that I wasn’t getting. As I said map() lets me apply a function to a set of things, and either gives me back the collection of things (when I call .collect()). What I wasn’t getting is that it doesn’t give me the new collection and an error… It gives me a Result.

So in this case, collect() was the correct place for the ?. My turbofish and type hinting in general was the problem. I had the hierarchy of the Vec and the Result flipped because of the nature of the operation. It’s safe to say that I was typehinting wrong everywhere and not seeing the whole “board”. Good to watch in future.

Note

sniff… poor kid

I’d like to think that I would have got there if I kept thinking it through, but, now the opportunity is lost to me. Couple of lessons learned there I guess.

`from_string()` solution

Alright, to continue twirling t’wards freedom, let’s get the from_string() functions wired up and test it.

Note

So ruddy, bloody brave!

// -- snip --
    pub fn from_string(dimensions: &str) -> Result<Parcel, ParseIntError> {
       // trim the \n 
       let numbers: Vec<i32> = dimensions
                               .trim_end()
                               .split("x")
                               .into_iter()
                               .map(|n| n.parse::<i32>())
                               .collect::<Result<Vec<i32>, ParseIntError>>()?;
        Ok(Parcel::new(numbers[0], numbers[1], numbers[2]))
    }
// -- snip --

running 4 tests
test parcel::tests::from_string ... ok
test parcel::tests::test_new ... ok
test parcel::tests::test_wrapping_paper ... ok
test parcel::tests::test_smallest_area ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

No… No Boom for this. Let’s just get out of here with the shirt on our backs shall we?

Bringing it all into `main.rs`

The first thing to do to bring our code into main.rs is to declare the module and then add the use statement(s). I’m going to bring both the Parcel module and the aoc_common crate that I’ve previously defined

mod parcel;
use aoc_common::read_challenge_input;
use parcel::Parcel;
// -- snip --

There. The reinforcements that we called up earlier are now ready, so we should be able to write this solution up neatly.

// -- snip --
fn main() {
    let dimensions = read_challenge_input("./input.txt"); // input is in the root folder which is
                                                           // where I'll be calling the cargo run
                                                           // from
                           
    let wraps: i32 = dimensions.unwrap().lines()
                                    .into_iter()
                                    .map(|l| Parcel::from_string(l))
                                    .map(|p| p.expect("This should be a set of dimensions").wrapping_paper())
                                    .sum();
    println!("{}", wraps);
    
}

3 lines in main and I have a result

:!cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home/midwitsanonymous/aoc/target/debug/day_2`
1586300

I promise that’s correct for my puzzle dimensions. And while it’s short and it passes, after my disastrous interaction with Claude earlier, my ego needs to produce something a little… goofier.

// -- snip --
fn main() -> Result<(), Box<dyn Error>> {
    // This is stupid
    println!("Hey Larry! Order {:?} feet of paper!",{
        read_challenge_input("./input.txt")?
            .lines()
            .into_iter()
            .map(|l| Parcel::from_string(l))
            .map(|p| p.expect("This should be a set of dimensions").wrapping_paper())
            .sum::<i32>();
    });

    Ok(())
}

Guh’hyuk!! Gorsh that’s silly!

What we’ve done here is make the main function return a Result<(), Box>. This lets us propagate any error we get inside main back out to the console. This requires that the last line within main returns a unit Struct wrapped in Ok(). Then, and I take full responsibility for this rediculosity, I put everything inside an expression inside the println! macro.

Let’s see what we get when passing a bad path into the read_challenge_input() call.

$!cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home/scratch/target/debug/day_2`
Error: FileNotFound("No such file or directory (os error 2)")

One of our lovely FileNotFound errors from our previous SideQuest.

Ok, fair enough, let us leave these Hollowed out lands of Part 1, and seek new Booms in the fairer shores of

(Dun-dun-na-na!)

Part 2

Here, we need to calculate the length of ribbon. Though, this may also work for getting bandages (you know, for all the scars… you get me).

To get the length of ribbon that we’ll need for our bows we need:

The perimeter of the smallest side
The cubic volume of the Parcel

You know the score

`smallest_perimeter()`

First we write the test

test `smallest_perimeter()`

// -- snip --
    #[test]
    fn test_perimeter() {
        let test = Parcel::new(1,2,3);
        assert_eq!(
            test.smallest_perimeter(),
            6
            )
    }

implementing `smallest_perimeter()`

The battle scars from our previous foray serve us well here. I’m basically just reusing the same solutions from smallest_area() again.

// -- snip --
    pub fn smallest_perimeter(&self) -> i32 {
        let p1 = (self.l * 2) + (self.w * 2);
        let p2 = (self.l * 2) + (self.h * 2);
        let p3 = (self.w * 2) + (self.h * 2);
        if p1 <= p2 && p1 <= p3 {
            p1
        } else if p2 <= p1 && p2 <= p3 {
            p2
        } else {
            p3
        }
    }

running 5 tests
test parcel::tests::test_smallest_area ... ok
test parcel::tests::test_new ... ok
test parcel::tests::test_perimeter ... ok
test parcel::tests::from_string ... ok
test parcel::tests::test_wrapping_paper ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Boom.

Let’s take the win and keep truckin’

`cubic_volume()` test

// -- snip --
    #[test]
    fn test_cubic_volume() {
        let test = Parcel::new(1,2,3);
        assert_eq!(
            test.cubic_volume(),
            6
            )
    }

implementing `cubic_volume()`


    pub fn cubic_volume(&self) -> i32 {
        self.l * self.w * self.h
    }

Isn’t that a cute little function? Lookit’im!

So let’s see how cargo feels about it

// -- snip --
running 6 tests
test parcel::tests::from_string ... ok
test parcel::tests::test_new ... ok
test parcel::tests::test_cubic_volume ... ok
test parcel::tests::test_perimeter ... ok
test parcel::tests::test_smallest_area ... ok
test parcel::tests::test_wrapping_paper ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Cubic Boom!

`ribbon()`

So now, all we need to do is take both of those functions and put them into a single function that gives us what we want.

`ribbon()` test

// -- snip --
    #[test]
    fn test_ribbon() {
        let test = Parcel::new(1,2,3);
        assert_eq!(
            test.ribbon(),
            12
            )
    }

And the implementation

// -- snip --
    pub fn ribbon(&self) -> i32 {
        self.smallest_perimeter() + self.cubic_volume()
    }

Let’s get Friend computer's thoughts on it all

// -- snip --
running 7 tests
test parcel::tests::from_string ... ok
test parcel::tests::test_new ... ok
test parcel::tests::test_cubic_volume ... ok
test parcel::tests::test_perimeter ... ok
test parcel::tests::test_ribbon ... ok
test parcel::tests::test_smallest_area ... ok
test parcel::tests::test_wrapping_paper ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

There we have it, the penultimate Boom.

Part 2 in main

OK, so to get our final solution we need to put all this together in main.rs. Which in this case is really just a case of copying what’s already in main() and redoing it.

Complete `main.rs`

mod parcel;
use aoc_common::read_challenge_input;
use parcel::Parcel;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let dimensions = read_challenge_input("./input.txt")?;
    let paper = dimensions
            .lines()
            .into_iter()
            .map(|l| Parcel::from_string(l))
            .map(|p| p.expect("This should be a set of dimensions").wrapping_paper())
            .sum::<i32>();
    let ribbon = dimensions
            .lines()
            .into_iter()
            .map(|l| Parcel::from_string(l))
            .map(|p| p.expect("This should be a set of dimensions").ribbon())
            .sum::<i32>();

    println!("Hey Larry! Order {} feet of paper, and {} of ribbon!", paper, ribbon);

    Ok(())
    
}

As we’re coming to a close, it felt right to let the goofy implementation from earlier go. To move on bright eyed and hopeful into a more mature place.

Nature’s healing.

Let’s run it and wrap this sucker up.

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home//target/debug/day_2`
Hey Larry! Order 1586300 feet of paper, and 3742592 of ribbon!

What’s that? Off in the distance…

Boom (oom, oom)

Note

sniff So proud

What do I need to take from this?

This one was a doozy, and if you read this far (thank you), you can probably spot the moment when the joy of solving this puzzle faded.

However, the positive note is that both the stumbling around, and the fumble with Claude, have reinforced the things I needed to learn, so hopefully those Rust Rookie Mistakes are now things of the past.

Part of the power of LLM’s is that they can really speed up the production of code, but when that’s not the goal, when the goal is the thinking and the making mistakes and massive dopamine hit of getting the code to run… well then that power is a curse.

I often find docs tough to read, especially in a new language, and especially when those docs are written to help experts, not necessarily to help new comers. I’ve found that asking for toy examples, or even just for guidance on idioms has been useful. Every now and then though, something like what happened earlier on happens and it seems like that isn’t a current limitation of the technology. It’s the nature of the beast.

When we make a stochastic puppet who’s job is to make itself easier to use and pleasant to talk to in most circumstances then using it to learn is a real risk. Not even including the risks of plagiarism, or of appealing to the lazy angels of our nature (and Lord knows mine are already strong enough), or of getting us to confuse familiarity with knowledge. There’s also the risk that the biases built in will make it default to doing “work” for us. Even when the work is what we want.

I don’t know how to manage this as a human, but today is another piece of data to help I guess.

Enough philosophising!

The sticking point of not seeing the difference between

Vec
Result, ParseIntError>

Feels like the kind of thing that you just have to see. That comes from getting reps in. That’s a good thing to keep in mind in the future.

Also thinking about closures holistically. Seeing the ‘end in the beginning’ so to speak. .collect(), or any of the other consumers will be in a specific relationship with the adaptors that came before it and it’d be good to get more reps in on that.

The & vs && is a good to know, and I’ll probably make that mistake every time I return the Rust after a short break.

TDD served me well here again, but it really only really mattered when I was thinking through from_string(), and even then, not enough to actually help solve the central problem. Just to tell me when I had a solution.

Coming from the python data-sciency space, TDD actually feels a little more like REPL-driven development, but just for stuff that doesn’t have an immediate output. If I make a polars LF in a Marimo notebook cell, I can see really easily if I have what I want. I don’t need to wire up a lot of API calls, or fixtures to see what I need. Maybe TDD is just another way of implementing the same kind of feedback loop? Maybe that’s where it’s useful.

Think about what you want > write the test > get feedback.

Again, that’s probably not shocking to people who practice TDD, but coming from my viewpoint it feels like a good model.

REPLs are really nice to have though.

Anyway, that’s more than enough for this one. Again, if you made it through with me, thank you for your time.

God’s speed.

The MidWit :wqa

Footnotes

Neovim by the way↩︎
And remember “MidWit”.↩︎
I asked Claude for help understanding this, the words are mine, but like I said, this was new to me↩︎
Also called BOMDAS in some places but I learned PEMDAS so that’s what I’m going with.↩︎
It’s hard to describe a function humorously, but maybe the test output will give us a giggle huh?↩︎
TM, TM, TM↩︎
I’m doing these puzzles to learn by solving problems. The feeling of figuring something out is the best feeling in the world. I had hoped that using Claude here might just help me not go down completely dead ends, instead, it robbed me of the game. If your response to this is that I’m using it wrong: Go back to bed please.↩︎

SideQuest 1:

The MidWit — Sun, 31 May 2026 00:00:00 GMT

Note

If you just want to jump straight to the whole implementation you can skip here

Problem

So far, all of the AOC puzzles have given me long strings of text as input, and the easiest way for me to use them has been to put them into a file called “./input.txt” and then read that file in. Now, obviously Rust has standard implementations for that but, in the process of solving the day 1 puzzle it occurred to me that it would be a good idea for me to practice things like writing my own types, errors, and functions, and setting up my own modules/crates to use, as is my prerogative.

Also, it seemed like an opportunity to practice a little Test Driven Development (TDD) which comes recommended in The Book. It would cost me nothing to try it out right?

Right!?

Spoiler: was TDD fine?

Day 1:

The MidWit — Fri, 29 May 2026 00:00:00 GMT

Note

You can find the text of the puzzle at here. I’ve put some fake input that should give me a result of -1 so when you see output ending in -1, that means my implementation is working.

Overview

The aim of this puzzle is to take in a long string of text, somewhat awkwardly, composed of “(” and “)”, and to iterate a counter up or down respectively until we come to a final floor (where Santa ends up after following the instructions).

Concepts

File IO
Iteration
control flow
mutability
wrapped value (Result)

Initial thoughts

So in python-land I would read in the input string and iterate over the characters with a for loop, checking each char and incrementing/decrementing a counter to get the final number… so that’s where I started.

Part 1

Reading in a text file.

So rather than using context manager to read the text and bind it to a variable, Rust has a function in the standard library: use std::fs::read_to_string;.

#| label: file-io-1

use std::fs::read_to_string;// bring the function into scope

fn main () {
    let input = read_to_string("./input.txt");// read the input
    println!("{}", input)//
}

This was my first hurdle

$ cargo rust
  Compiling day_1 v0.1.0 (/path/to/day_1/main)
error[E0277]: `Result` doesn't implement `std::fmt::Display`
 --> src/main.rs:5:20
  |
5 |     println!("{}", input)//
  |               --   ^^^^^ `Result` cannot be formatted with the default formatter
  |               |
  |               required by this formatting parameter
  |
  = help: the trait `std::fmt::Display` is not implemented for `Result`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead

For more information about this error, try `rustc --explain E0277`.
error: could not compile `day_1` (bin "day_1") due to 1 previous error

read_to_string doesn’t just return a String that I can manipulate directly (of course!) it returns a Result, and that creates all sorts of… opportunities for learning.

The value I want is inside a Result rather than directly available, so I gotta deal with that
The Result doesn’t have the Display Trait so I need to put one of the formatting bugs inside the “{}”

1 of those is easy to deal with:

#| label: file-io-2
use std::fs::read_to_string;// bring the function into scope

fn main () {
    let input = read_to_string("./input.txt");// read the input
    println!("{:?}", input)// put the debug syntax into the println! macro
}

which gives me

$cargo run
   Compiling day_1 v0.1.0 (path/to/day_1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/day_1`
Ok("()(((()()))()((()))())()())\n")

So we can see that the output shows us that my input is wrapped in Ok(), which is one of the variants of the Result enum. Which in some ways is fine, but I want the actual feed of characters, so I have a few options.

.unwrap() which will either give me the string directly or Panic
.expect() which is basically the same, but I can put an error message in to help me.
Properly match on the Result and either get the content or handle the error.

#| label: file-io-expect
use std::fs::read_to_string;// bring the function into scope

fn main () {
    let input = read_to_string("./input.txt");// read the input
    println!("{}", input.expect("no text here my dude"))// trying expect
}

$cargo run
   Compiling day_1 v0.1.0 (path/to/day_1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
     Running `target/debug/day_1`
()(((()()))()((()))())()())

So that did work, but everything I’ve read says that both unwrap and expect are great tools for rapid iteration without getting bogged down, but that they shouldn’t be used in production code… and yes I’m not writing production code, but if I’m trying to learn more than just the basics, I should probably aim in that direction.

match

A match expression is a way to check the state of an object and control what happens based on what’s there. It’s very similar to the if/else if/else concept, but it can be a lot more ergonomic depending on what you’re checking, and enums are a great usecase for it. Python actually has a similar concept also called a match expression but I hadn’t come across that in my own work until recently so I would have relied on if/elif/else in previous work. I’m trying to practice “idiomatic” rust patterns here so lets match:

#| label: file-io-match
use std::fs::read_to_string;// bring the function into scope

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => println!("{}", s),// match unpacks the value for us
        Err(e) => println!("We got an error {}", e),// Printing a custom message and the Error
    }
}

OK so that gives us the actual input string as something I can use, so let me move on to actually tracking floors.

One step up N steps down

So what were trying to do is, starting at 0 (the ground floor) find the floor number that Santa ends up on after taking all the steps indicated in the input: “(” = up 1, “)” = down 1. Rust will let us iterate over the characters in a String by calling .chars(). This gives us back a collection we can iterate over.

Coming from python, my instinct is to reach for a loop and if/else

#| label: immutable-loop
// assume the main function and prelude

let floor = 0;
for c in input.chars() {
    if c == "(" {
        floor += 1 
    } else if c == ")" {
        floor -= 1 
    } else {
        floor
    }
};
println!("{}", floor);

Which brings me to a (drum roll please) RUST ROOKIE MISTAKE : mutability.

  --> src/main.rs:10:21
   |
 7 |             let floor = 0;
   |                 ----- first assignment to `floor`
...
10 |                     floor += 1
   |                     ^^^^^^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
 7 |             let mut floor = 0;
   |                 +++

error[E0384]: cannot assign twice to immutable variable `floor`
  --> src/main.rs:12:21
   |
 7 |             let floor = 0;
   |                 ----- first assignment to `floor`
...
12 |                     floor -= 1
   |                     ^^^^^^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
 7 |             let mut floor = 0;
   |                 +++

For more information about this error, try `rustc --explain E0384`.

Rust, cause it knows I’m a midwit, makes things immutable by default, meaning that once I bind a value to a variable I can’t change it… unless (“unless”) I specifically say that that value is mutable. There’s lots of really good reasons for this, but if you’re reading this post and you haven’t already seen those… then… I mean… welcome, I guess.

Anyway, fortunately this one is easy to fix:

#| label: mutable-loop
// assume the main function and prelude

let mut floor = 0;
for c in input.chars() {
    if c == "(" {
        floor += 1 
    } else if c == ")" {
        floor -= 1 
    } else {
        floor
    }
};
println!("{}", floor);

And… that gave me back the correct answer (for part 1 at least). Boom. I’ve written more than hello world. And yet…

Closures

While the for loop is legitimate rust, an this solution works, it’s not really, mutability and wrapping aside, that different from how I would solve a short problem like this in python, which ain’t really my goal here. So I guess I better try tackling this with a closure.

My main problem with closures isn’t the concept so much as the number of possible options, and there’s no way to learn these except to use them enough times. I really need to write a cheat sheet for them that I can look up later but for now, I’m going to ask my buddy Claude to recommend one¹, or more accurately to recommend an iterator adapter which will accept a closure and let me do the thing.

Fold

So again, let’s think about what the puzzle wants:

Starting at 0, iterate over a collection of chars incrementing or decrementing a number (accumulating), producing a count of the number of up or down steps we’ve taken. This looks like a job for .fold().

#| label: closure-fold
use std::fs::read_to_string;// bring the function into scope

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input { // match on input
        Ok(s) => { // when input is Ok()
        let result = s.chars().fold( // bind the product of the closure to result
                // 0, is the starting number
                // |acc, is the variable name for 0 
                // c| is the variable name for each char in input for each loop
                0, |acc, c| match c { // matching on c
                '(' => acc + 1, // incrementing acc
                ')' => acc -1, // decrementing acc
                _ => acc // using the wildcard so that the match is exhaustive
            });
        println!("{}",result); //printing the result
        },
        Err(e) => println!("We got an error {}", e),// Printing a custom message and the Error
    }
}

#| label: closure-fold-output
$cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/day_1`
-1

So .fold() lets me set a starting value (in the above case it’s 0), then bind that value to acc (standing for accumulator) and then bind the current char to c while looping over input, accumulating a count of steps for each c.

As someone who’s not a programmer, and who writes pretty quick and dirty python, I have to say I really like the closure approach. I can’t really say why but it feels like it reduced some typing for me (for c in chars{ if/else}), but some of that is also just the match implementation as well.

Refactoring

One of the things that I find challenging is reading deeply nested code, or it’s probably more accurate to say that I find it really hard to debug deeply nested code. My imposter-syndrome self likes to tell me that real coders don’t have a problem with this, but my better angels remind me that: - I don’t want to be a real coder so I should just be happy for those that don’t have this problem, and - There’s probably loads of really talented engineers who also struggle with this.

All this to say that I prefer when the code is split up into smaller blocks ² that I can reason about individually. While this isn’t exactly deeply nested, it is a few layers deep between the 2 match blocks, and so now might be a good time to think about pulling some of this apart so I can put it back together. Especially given that there is a part two to this puzzle, so re-usability might be nice to have…

Taking steps.

The first clear thing I can do is pull the ‘char’ matching out into it’s own function:

Take a char and an i32 and then give back an updated i32

#| label: take-step-definition

//take step function
//this just does what I was doing in the fold but in a function that I can
//use in the .fold() closure
fn take_step(c: char, value: i32) -> i32 {
    match c {
        '(' => value + 1,
        ')' => value -1, 
        _ => value
    }
}

Ok, that might not be the most perfect rust function but it does what I want it to do. I should probably make it return a Result and write some proper Error handling, but baby steps here (this is already much too long).

So now my solution is

#| label: function-fold-1

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
        let result = s.chars().fold(
                0, |acc, c| take_step(c, acc)
            );
        println!("{}",result);
        },
        Err(e) => println!("We got an error {}", e),// Printing a custom message and the Error
    }
}

This compiles so the refactor works (boom) but also I find it easier to see what’s going on inside the .fold() (second boom).

This also prompted me to think about handling errors and other ways I could refactor to get rid of other nesting in my main function. Specifically I could re-work the file I/O to handle errors and let me drop that outer match expression but I’m going to call that my first sidequest in which our hero write a module to handle reading challenge input that I can use in all the other day’s of AOC. But for now let’s move onto part 2.

Part 2: Don’t go down there! It’s dark..

So for the second part, I have to find the first char that causes Santa to enter the basement (brings the counter below 0).

In python land I would use some kind of while loop here and enumerate over the input string; but I’d like to see if there is a way to do this with a closure?

I know that the .enumerate() method will give me back both the index and the values in a collection so adding that into my adapter chain is a good start, but .fold() isn’t really the move here because we want to stop at a particular point, not take the whole collection.

A little searching tells me that .find() might do what I want, and Claude suggested .scan(). I’m going to try .find() first and see what happens.

#| label: find-1

use std::fs::read_to_string;// bring the function into scope

fn take_step(c: char, value: i32) -> i32 {
// -- snip --
}

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
// -- snip --
        let floor = 0;
        let basement = s.chars()
            .enumerate()
            .find(|(i,c)|
                take_step(c, floor) == -1
                );

        },
// -- snip --
    }
}

This was my first attempt and it was really just an attempt to see what I get back from .find(). Here’s what happened.

#| label: find-1-output
  --> src/main.rs:22:27
   |
22 |                 take_step(c, floor) == -1
   |                 --------- ^ expected `char`, found `&char`
   |                 |
   |                 arguments to this function are incorrect
   |
note: function defined here
  --> src/main.rs:3:4
   |
 3 | fn take_step(c: char, value: i32) -> i32 {
   |    ^^^^^^^^^ -------
help: consider dereferencing the borrow
   |
22 |                 take_step(*c, floor) == -1
   |                           +

Ok, so what this is telling me is that c is getting passed into the function as a borrow rather than the actual char and so I need to deref. I’m not going to pretend I fully understand why right now, but I do know that I just need to do what the compiler tells me to fix it. And having done so we can see some output.

#| label: find-1-output-2
warning: unused variable: `i`
  --> src/main.rs:21:21
   |
21 |             .find(|(i,c)|
   |                     ^ help: if this is intentional, prefix it with an underscore: `_i`
   |
   = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

warning: `day_1` (bin "day_1") generated 1 warning (run `cargo fix --bin "day_1" -p day_1` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/day_1`
-1
Some((1, ')'))

For now I’m going to ignore the unused_variables warning and focus on the fact that .find() is returning an Option<(i,c)> which is good news, if a little confusing to read. I’m not sure that this value is right though, so I’m going to do a little println! debugging to see what’s happening.

#| label: find-1-println
use std::fs::read_to_string;// bring the function into scope

fn take_step(c: char, value: i32) -> i32 {
// -- snip --
}

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
// -- snip --
        let floor = 0;
        let basement = s.chars()
            .enumerate()
            .find(|(i,c)| {
                println!("floor = {}", floor);
                println!("index = {}", i);
                println!("char = {}", c);
                take_step(*c, floor) == -1
            });
// -- snip --
    }
}

Which gives me

#| label: find-1-println-output
// --snip --
floor = 0
index = 0
char = (
floor = 0
index = 1
char = )
Some((1, ')'))

I know, you saw the problem already and have been shouting at me for the last few paragraphs, but… “MidWit” remember?

So floor isn’t getting updated at any point which means while I’m actually getting a technically correct answer (which is the best kind of correct) it’s not in the spirit of the puzzle. Really I’m just finding the first character that subtracts 1 from 0… let’s see if I can fix it.

#| label: find-1-update
use std::fs::read_to_string;// bring the function into scope

fn take_step(c: char, value: i32) -> i32 {
// -- snip --
}

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
// -- snip --
        let floor = 0;
        let basement = s.chars()
            .enumerate()
            .find(|(i,c)| {
                println!("floor = {}", floor);
                println!("index = {}", i);
                println!("char = {}", c);
                floor += take_step(*c, floor); // Updating floor here
                floor == -1
            });
// -- snip --
    }
}

#| label: find-1-update-output
// -- snip --

floor = 2001801
index = 22
char = (
floor = 4003603
index = 23
char = )
floor = 8007205
index = 24
char = (
floor = 16014411
index = 25
char = )
floor = 32028821
index = 26
char = )
floor = 64057641
index = 27
char =

None

Sad Trombone

Ok, so, again you probably saw what I was doing wrong here: I’m not just taking a step each round. I’m adding floor to itself and then the take_step value. So find() doesn’t easily keep track of the value we’re trying to update well. While I could spend ages thinking about how to manage this, it might be time to see if .scan(), which is more similar to .fold(), can do for us.

Scan

Based on the docs, .scan() gives back another iterator and so that will need processing as well to get the actual point at which Santa enters the basement for the first time. I’m going to try to build this chain piece by piece starting with the scan.

#| label: scan-1-start
// -- snip --

fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
// -- snip --
        let basement = s.chars()
            .scan(0, |acc, c| {
                take_step(c, *acc);
                Some(*acc)
            }
            
            );
        println!("{:?}", basement);

#| label: scan-1-start-output
// -- snip --
Scan { iter: Chars(['(', ')', '(', '(', '(', '(', ')', '(', ')', ')', ')', '(', ')', '(', '(', '(', ')', ')', ')', '(', ')', ')',
 '(', ')', '(', ')', ')', '\n']), state: 0 }

Great, we have a Scan object which is a collection of chars and a state… great… I * definitely know what to do with that… def’nitly.

What do I know that can help me figure this out?

A lot of closures are ‘lazy’ meaning that I would need to .collect() or otherwise process it.
I still need to get a particular index, so .enumerate() is still going to be needed.
Speaking of which, .find() is probably going to come into it’s own here.
Claude recommended .scan() so I might not be on the right track with .scan() either, but that’s probably not as helpful to think about right now.

Let me start by seeing what happens when I .collect() the .scan().

#| label: scan-1-collect-output
error[E0283]: type annotations needed
  --> src/main.rs:25:35
   |
25 |         println!("{:?}", basement.collect());
   |                                   ^^^^^^^ cannot infer type of the type parameter `B` declared on the method `collect`
   |
   = note: cannot satisfy `_: FromIterator`
note: required by a bound in `collect`
  --> /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/iter/traits/iterator.rs:2051:4
help: consider specifying the generic argument
   |
25 |         println!("{:?}", basement.collect::>());
   |                                          ++++++++++

For more information about this error, try `rustc --explain E0283`.

Say it with me folks!! Rust. Rookie. Mistake! The compiler needs to know what I’m trying to make so the code needs a turbofish ³ where the type is specified.

#| label: scan-1-turbofish
// -- snip --
    
        let basement = s.chars()
            .scan(0, |acc, c| {
                take_step(c, *acc);
                Some(*acc)
            }
            
            );
        println!("{:?}", basement.collect::<Vec<_>>());
// -- snip --

That gives me back a vector of 0s… because of course it does. I’m not sure what that means yet either, but I’m gonna keep going. We know that we’re looking for an index as I said, so my next thought is to add .enumerate() to the chain, as this will give me a Vec<(index, state)> (I think).

#| label: scan-1-enumerate
// -- snip --
    
        let basement = s.chars()
            .scan(0, |acc, c| {
                take_step(c, *acc);
                Some(*acc)
            }
            
            )
            .enumerate();
        println!("{:?}", basement.collect::<Vec<_>>());
// -- snip --

#| label: scan-1-enumerate-output
// -- snip --
[(0, 0), (1, 0), (2, 0), (3, 0), (4, 0), (5, 0), (6, 0), (7, 0), (8, 0), (9, 0), (10, 0), (11, 0), (12, 0), (13, 0), (14, 0), (15
, 0), (16, 0), (17, 0), (18, 0), (19, 0), (20, 0), (21, 0), (22, 0), (23, 0), (24, 0), (25, 0), (26, 0), (27, 0)]
// -- snip --

Yes! Well… half yes. I’m getting the tuple I expect (I think), but the fact that the second item is always 0 leads me to believe that something is going wrong in the way .scan() is interacting with my take_step function. Rather than move onto adding the .find() part of the chain I’m going to unpack the take_step functionality and do it explicitly inside the closure

#| label: scan-1-explicit
// -- snip --
        let basement = s.chars()
            .scan(0, |acc, c| {
                acc += match c {
                    '(' => acc + 1,
                    ')' => acc -1, 
                    _ => acc
                };
                Some(*acc)
            })
            .enumerate();
        println!("{:?}", basement.collect::<Vec<_>>());
// -- snip --

Oh boy, this next one is a doozy

#| label: scan-1-explicit-output
// -- snip --
  --> src/main.rs:21:32
   |
21 |                     '(' => acc + 1,
   |                            --- ^ - {integer}
   |                            |
   |                            &mut {integer}
   |
   = note: an implementation for `&{integer} + {integer}` exists
help: consider reborrowing this side
   |
21 |                     '(' => &*acc + 1,
   |                            ++

error[E0369]: cannot subtract `{integer}` from `&mut {integer}`
  --> src/main.rs:22:32
   |
22 |                     ')' => acc -1,
   |                            --- ^- {integer}
   |                            |
   |                            &mut {integer}
   |
   = note: an implementation for `&{integer} - {integer}` exists
help: consider reborrowing this side
   |
22 |                     ')' => &*acc -1,
   |                            ++
// -- snip --

OK, so, again, I’m not sure if this is accurately diagnosing what the issue was earlier, but it is showing me that acc is mutably borrowed inside the closure, so if I’m understanding correctly then it means I need to deref acc before the match, also if I leave acc in the match arms I’ll end up with the same problem I had with the earlier find: doubling.

#| label: scan-1-deref
// -- snip --
        let basement = s.chars()
            .scan(0, |acc, c| {
                *acc += match c {
                    '(' => 1,
                    ')' => -1, 
                    _ => 0
                };
                Some(*acc)
            })
            .enumerate();
        println!("{:?}", basement.collect::<Vec<_>>());
// -- snip --

We have a third boom.

#| label: scan-1-deref-output
// -- snip --
[(0, 1), (1, 0), (2, 1), (3, 2), (4, 3), (5, 4), (6, 3), (7, 4), (8, 3), (9, 2), (10, 1), (11, 2), (12, 1), (13, 2), (14, 3), (15, 4), (16, 3), (17, 2), (18, 1), (19, 2), (20, 1), (21, 0), (22, 1), (23, 0), (24, 1), (25, 0), (26, -1), (27, -1)]
// -- snip --

So the state is now updating as we run through it, meaning that now I just need to .find() the first time we get a -1 in the state, which we can see is at index 26 in this output.

What we have now is the vec of (i, state) that we need to pass into .find(), and because .find() takes only one parameter I need to pass them in in that format rather than as separate arguments.

#| label: scan-1-find
// -- snip --
        let basement = s.chars()
            .scan(0, |acc, c| {
                *acc += match c {
                    '(' => 1,
                    ')' => -1, 
                    _ => 0
                };
                Some(*acc)
            })
            .enumerate()
            .find(|(i, state)| *state == -1);
        println!("{:?}", basement.collect::<Vec<_>>());
// -- snip --

#| label: scan-1-find-output
// -- snip --
  --> src/main.rs:29:35
   |
29 |         println!("{:?}", basement.collect::>());
   |                                   ^^^^^^^ method cannot be called on `Option<(usize, {integer})>` due to unsatisfied trait b
ounds
   |
   = note: the following trait bounds were not satisfied:
           `Option<(usize, {integer})>: Iterator`
           which is required by `&mut Option<(usize, {integer})>: Iterator`

For more information about this error, try `rustc --explain E0599`.
// -- snip --

Ok, so .find() returns an Option rather than a collection that needs to be .collect()ed so I need to drop that bit, so long turbofish!

#| label: scan-find-println
// -- snip --
    println!("{}", basement);
// -- snip --

Ladies and Jellyspoons, we have reached the 4th boom.

#| label: scan-find-println-output
// -- snip --
warning: unused variable: `i`
  --> src/main.rs:28:21
   |
28 |             .find(|(i, state)| *state == -1);
   |                     ^ help: if this is intentional, prefix it with an underscore: `_i`
   |
   = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

warning: `day_1` (bin "day_1") generated 1 warning (run `cargo fix --bin "day_1" -p day_1` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/day_1`
-1
Some((26, -1))
// -- snip --

OK, so we have the Some(tuple) that shows us the index and the state we want. So functionally we have the output we want. The eagle eyed amongst you will have spotted that the last char in input is '\n' and so the wildcard in the match is doing what we want as well and leaving acc as it is.

Thus we have out answer to both parts!… except…

As I said up above I’m trying to write towards production code, and while I have my answer, the output is ugly as fu… it doesn’t look great. So, it might be worth it to try to make the output prettier.

Prettifying

This is one of the places .unwrap() may work well because there is a Some that we just want to get the value out of.

#| label: scan-unwrap
// -- snip --
        let basement = s.chars()
            .scan(0, |acc, c| {
                *acc += match c {
                    '(' => 1,
                    ')' => -1, 
                    _ => 0
                };
                Some(*acc)
            })
            .enumerate()
            .find(|(i, state)| *state == -1)
            .unwrap();
// -- snip --

Which gives us back the tuple (26,-1). Since we just want the zeroth item in the tuple we could just destructure it with . syntax as well to just get the 26 back in out output. However, I want to deal with that unused_variables warning now and I think that .map() might let me do that. .map() will let me create a new iterator and apply a new closure to it in line, letting me destructure the tuple I get back from .find().

#| label: pretty-map
// -- snip --
            .enumerate()
            .find(|(i, state)| *state == -1)
            .map(|(i, state)| i as i32)
            .unwrap();
// -- snip --

#| label: pretty-map-output
// -- snip --
warning: unused variable: `state`
  --> src/main.rs:29:23
   |
29 |             .map(|(i, state)| i as i32)
   |                       ^^^^^ help: if this is intentional, prefix it with an underscore: `_state`
   |
   = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

warning: unused variable: `i`
  --> src/main.rs:28:21
   |
28 |             .find(|(i, state)| *state == -1)
   |                     ^ help: if this is intentional, prefix it with an underscore: `_i`

warning: `day_1` (bin "day_1") generated 2 warnings (run `cargo fix --bin "day_1" -p day_1` to apply 2 suggestions)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.22s
     Running \`target/debug/day_1\`
-1
26
// -- snip --

OK, so the compiler is telling me that if I want to get rid of the unused_variables warning I just need to prefix the variable names with “_” and so let me do that one last time and check the output.

Final implementation

#| label: final-implementation
use std::fs::read_to_string;// bring the function into scope

fn take_step(c: char, value: i32) -> i32 {
    match c {
        '(' => value + 1,
        ')' => value -1, 
        _ => value
    }
}
fn main () {
    let input = read_to_string("./input.txt");// read the input
    match input {
        Ok(s) => {
        let result = s.chars().fold(
                0, |acc, c| take_step(c, acc)
            );
        println!("We're on floot {}",result);
        let basement = s.chars()
            .scan(0, |acc, c| {
                *acc += match c {
                    '(' => 1,
                    ')' => -1, 
                    _ => 0
                };
                Some(*acc)
            })
            .enumerate()
            .find(|(_i, state)| *state == -1)
            .map(|(i, _state)| i as i32)
            .unwrap();
        println!("The first time we hit the basement is {}", basement);

        },
        Err(e) => println!("We got an error {}", e),// Printing a custom message and the Error
    }
}

#| label: final-output
$cargo run
   Compiling day_1 v0.1.0 (path/to/day_1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/day_1`
We're on floor -1
The first time we hit the basement is 26

Ultimate BOOM!.

We have a solution.

It’s definitely not perfect and it spawned at least one sidequest but as a fledgling rust writer I think I can be pretty happy with it.

What do I need to take from this?

Closures are great, but there’s a lot of adaptors and, frankly the documentation isn’t that easy to parse.
- .find() lets us look for a condition
- .fold() lets us accumulate a value over a collection (at least as far as I understand it)
- .scan() is like .fold(), except it gives back a collection and a state item that we can track
I need to learn more about referencing and dereferencing, there is a principle there around how something gets passed into a closure, but it hasn’t clicked for me yet.
The compiler is a good ally, especially if the issue is rudimentary.
Walking through the problem is a good idea, even if it’s after the fact.
- I wrote this up after I had a solved, but I was taking checkpoints as I went so that I could try to consolidate things.
- I definitely used Claude to help me parse the errors, and as I said above to suggest adaptors that might be useful to me. It would often tell me to just reach for a for loop though and I’d have to do a lot to get it to stick with my learning goals. Working with an LLM definitely saved time, but when my aim is to learn, not to meet KPIs as a developer this isn’t ideal. I have a ‘Rust-coach’ skill which often works well, but I’ve found that it’s tough to keep it from being too helpful and it’s better for me to just not use one when I’m tired: too tempting to just get an answer, which isn’t the same as learning a thing.
This write up took way too long. In future it would be better to hit highlights better, but then I don’t really know what qualifies as a highlight this early in the show.
Refactoring is good even if it doesn’t actually get reused.
- I certainly could have updated take_step() to accomodated Part 2, but as a learning excercise it was worth doing even though it just contributed to Part 1.

Anyway, that’s too much for a single post, espeshally a first’un.

God’s speed.

The MidWit:wqa

Footnotes

I really don’t like using LLMs for learning, for too many reasons to go into here, but honestly, as a docs reader I do think they are great, and I’m not above saving myself days of reading through docs or reddit to get an answer. If you think I got Claude to give me the whole solution, then you probably think I got Claude to write this whole post, so there’s not really a lot I can do about that. We’re all just tryin’ to figure this out I suppose.↩︎
I’m not qualified to say that this is ‘right’ or ‘wrong’ I’m saying that my brain and eyes prefer it. Maybe it is better to wire everything together in longer chunks, but I’m > 40 years old and I’m trying to learn what I’m trying to learn, so… get off my back!↩︎
If you think for one minute that the fact that it’s called a turbofish isn’t a big reason why I’m trying to learn rust, you’re out of your mind.↩︎

midwitsanonymous

Day 2:

Overview

Concepts

Limitations - Modules and Functions and tests (Oh My!)

Set up

Part 1

Formulae

Parcel Struct

test_new()

Implement new()

Makin’ calculations

test_smallest_area()

Perfectly fine Catastrophic smallest_area()

And and And

&

&&

Fixing smallest_area()

wrapping_paper()

test_wrapping()

implementing wrapping_paper()

from_string()

Test from_string()

First attempt

map -> Result

Second attempt: trying ?

Getting Explicit: Dropping ?

What do I think I know?

Trying Option

Getting “help”

How I was wrong.

from_string() solution

Bringing it all into main.rs

Part 2

smallest_perimeter()

test smallest_perimeter()

implementing smallest_perimeter()

cubic_volume() test

implementing cubic_volume()

ribbon()

ribbon() test

Part 2 in main

Complete main.rs

What do I need to take from this?

Enough philosophising!

Footnotes

SideQuest 1:

Problem

Day 1:

Overview

Concepts

Initial thoughts

Part 1

Reading in a text file.

match

One step up N steps down

Closures

Fold

Refactoring

Taking steps.

Part 2: Don’t go down there! It’s dark..

Scan

Prettifying

Final implementation

What do I need to take from this?

Footnotes

Parcel `Struct`

`test_new()`

Implement `new()`

`test_smallest_area()`

Perfectly fine Catastrophic `smallest_area()`

`&`

`&&`

Fixing `smallest_area()`

`wrapping_paper()`

`test_wrapping()`

implementing `wrapping_paper()`

`from_string()`

Test `from_string()`

`map` -> `Result`

Second attempt: trying `?`

Getting Explicit: Dropping `?`

Trying `Option`

`from_string()` solution

Bringing it all into `main.rs`

`smallest_perimeter()`

test `smallest_perimeter()`

implementing `smallest_perimeter()`

`cubic_volume()` test

implementing `cubic_volume()`

`ribbon()`

`ribbon()` test

Complete `main.rs`