You can lay out your types exactly how you want in Rust, just by using the `#[repr(C)]` or `#[repr(packed)]` attributes to guarantee an ordering of the fields. So,

> rust might not give you great insight into how it lays things out

Is not true, and this is one of the first things you will learn when you try any sort of FFI. So

> (or it's not as well known or talked about...)

Is not true.

Yes, I think he meant that it would be a bad idea to lock all of the type parameters to the same type, because all closures have different types. So you wouldn't be able to do something like this

    compose(|x| x, |x| x)

because the closures have the same type.

Because the closures don't have the same type, if I'm following you correctly.

Because the parameters demand the same type (and for the return value), but the supplied parameters are not the same type because the only way to get that is to pass in exactly the same instance of the closure.

It's a fun little thing, and a good example of why impl Trait in argument position is a really nice addition to Rust, even though based on what we were originally excited about (impl Trait in return position for returning Iterators and other such things), the argument position form didn't seem so important.