Thanks for the extended write up! I’m starting to get more of a feel for what the conpiler is doing behind the scenes.

I was going to ask a follow-up question about why there are instances of generics in traits that are never used:

// I2C SDA pin
pub trait SDAPin<I2C> {
    fn setup(&self);
}

But I think I get it. This allows multiple nearly identical implementations of this trait that vary only by the concrete type used.

This lets the macro implicitly tie certain hardware pins to certain register banks while maintaining a common setup() function for the SDAPin trait.

Neat!

Something else to consider is how a function returns an owned value and why knowing the size of a struct at compile time is required for that. At first this might seem like a simple thing if you think about ownership in an abstract sense, but when you actually start to think about how it’s implemented you can start to see some of the complexity.

Consider the following code:

use std::any::type_name;
use std::default::Default;

#[derive(Default, Debug)]
struct Foo {
    x: u32,
}

#[derive(Default, Debug)]
struct Bar {
    y: f32,
}

fn frobnicate<T: Default>() -> T {
    println!("Creating a new {}", type_name::<T>());
    Default::default()
}

pub fn main() {
    let foo: Foo = frobnicate::<Foo>();
    let bar: Bar = frobnicate::<Bar>();
    println!("Made a pair of owned {:?} and {:?}", foo, bar);
}

Where is the memory for foo and bar allocated at? It’s on the stack of the main() function. But the Foo and Bar instances are constructed inside of the call to default() inside of frobnicate(), so how is that memory ending up in the stack of main()? First, lets break this down using what I explained previously about generics being specialized at compile time. This code is roughly equivalent to the following (unchanged parts elided for brevity):

fn default_Foo() -> Foo {
  Foo {
    x: 0,
  }
}

fn default_Bar() -> Bar {
  Bar {
    y: 0.0,
  }
}

fn frobnicate_Foo() -> Foo {
  println!("Creating a new Foo"); // technically there's a genericized version of type_name() invoked here
  default_Foo()
}

fn frobnicate_Bar() -> Bar {
  println!("Creating a new Bar");
  default_Bar()
}

pub fn main() {
  let foo: Foo = frobnicate_Foo();
  let bar: Bar = frobnicate_Bar();
  println!("Made a pair of owned {:?} and {:?}", foo, bar);
}

But this still doesn’t explain how the Foo instance created in default_Foo() ends up on the stack of main(). The answer to that is that Rust is pulling a fast one and there’s a hidden argument on all these functions. The code can’t actually be expressed in Rust in a way that clearly illustrates this, so here’s the C equivalent of the previous Rust code:

struct Foo {
    unsigned int x;
};

void default_Foo(struct Foo *foo) {
    foo->x = 0;
}

struct Bar {
    float y;
};

void default_Bar(struct Bar *bar) {
    bar->y = 0.0;
}

void frobnicate_Foo(struct Foo *foo) {
    printf("Creating a new Foo\n");
    default_Foo(foo);
}

void frobnicate_Bar(struct Bar *bar) {
    printf("Creating a new Bar\n");
    default_Bar(bar);
}

void main() {
    struct Foo foo;
    struct Bar bar;
    
    frobnicate_Foo(&foo);
    frobnicate_Bar(&bar);
    printf("Made a pair of owned Foo { x: %u } and Bar { y: %f }\n", foo.x, bar.y);
}

Now that you can see the way that foo and bar are allocated on the stack of main() hopefully you can also see why knowing at compile time what the size of Foo and Bar are is important, otherwise how could the compiler make sure enough space has been allocated on the stack. Now consider what might happen if you tried to return a impl Default from frobnicate() instead of using generics. Setting aside that there would be no way to indicate which version of default() to invoke, if the compiler didn’t know what the concrete type being returned from frobnicate() was, how would it be sure it had allocated enough room on the stack of main() to store the return value?