603: Functor Laws in Practice

The Problem This Solves

// You probably write this all the time:
let result = some_option
 .map(parse_string)
 .map(validate_value)
 .map(format_output);

// You trust this is equivalent to:
let result = some_option.map(|s| format_output(validate_value(parse_string(s))));

The Intuition

How It Works in Rust

trait Functor {
 type Inner;          // the A in Container<A>
 type Mapped<B>;      // the Container<B> you get after mapping
 fn fmap<B>(self, f: impl FnMut(Self::Inner) -> B) -> Self::Mapped<B>;
}

impl<A> Functor for Option<A> {
 type Inner = A;
 type Mapped<B> = Option<B>;
 fn fmap<B>(self, f: impl FnMut(A) -> B) -> Option<B> {
     self.map(f)  // delegate to the built-in map
 }
}

impl<A, E> Functor for Result<A, E> {
 type Inner = A;
 type Mapped<B> = Result<B, E>;
 fn fmap<B>(self, f: impl FnMut(A) -> B) -> Result<B, E> {
     self.map(f)  // only transforms the Ok side
 }
}

impl<A> Functor for Vec<A> {
 type Inner = A;
 type Mapped<B> = Vec<B>;
 fn fmap<B>(self, f: impl FnMut(A) -> B) -> Vec<B> {
     self.into_iter().map(f).collect()
 }
}

fn check_identity_option<A: Clone + PartialEq>(x: Option<A>) -> bool {
 x.clone().fmap(|v| v) == x  // map with identity must return original
}

assert!(check_identity_option(Some(42)));   // true
assert!(check_identity_option::<i32>(None)); // true

fn check_composition_option<A, B, C>(
 x: Option<A>,
 f: impl Fn(A) -> B + Clone,
 g: impl Fn(B) -> C,
) -> bool
where A: Clone, B: Clone + PartialEq, C: PartialEq,
{
 let composed   = x.clone().fmap(|a| g(f(a)));  // one fmap with g∘f
 let sequential = x.fmap(f).fmap(g);             // two fmaps in sequence
 composed == sequential
}

let f = |x: i32| x * 2;
let g = |x: i32| x + 1;
assert!(check_composition_option(Some(5), f, g));  // true

// Also verify for Vec:
let xs = vec![1, 2, 3, 4, 5];
let composed:   Vec<i32> = xs.clone().fmap(|x| g(f(x)));
let sequential: Vec<i32> = xs.clone().fmap(f).fmap(g);
assert_eq!(composed, sequential);  // Law 2 holds for Vec

// This would break Law 1:
struct CountingBox<T> { value: T, count: usize }
// After .fmap(|x| x): count would be 1, but original has count 0 → not equal
// Identity law violated → NOT a valid Functor

What This Unlocks

• Confident chaining. You can replace `.map(f).map(g)` with `.map(|x| g(f(x)))` in any law-abiding Functor — same result, often faster (one pass instead of two).
• Property-based testing for your own types. The law-check functions are reusable templates. Add them to your test suite with `proptest` to verify your custom `map` implementations automatically for thousands of random inputs.
• Generic code that works across all Functors. Once `Option`, `Result`, and `Vec` all implement the same `Functor` trait, you can write algorithms that work over any of them — parsing pipelines, validation chains, transformation layers — without specializing for each container.

Key Differences