Unfortunately this crate currently relies on the assumption that an enum containing fields of type T has the same layout as an enum containing MaybeUninit<T>. However, this is not always the case. It is mentioned in the rust docs of MaybeUninit that

types containing a field of type T may be laid out (and sized) differently than if that field were MaybeUninit<T>

Here is a test that fails for that reason:

#[derive(AddrOfEnum, PartialEq, Eq)]
enum MyOption<T> {
    None,
    Some(T),
}

#[test]
fn test_option() {
    let some = MyOption::Some(false);

    match &some {
        MyOption::Some(item) => {
            assert_eq!(item as *const bool, addr_of_enum!(&some, Some, 0)); // <- this will fail (off by one)
        }
        _ => panic!(),
    }
}

In this specific example, the compiler does niche optimization because it knows that only 0 and 1 are valid values for bool, so it can use one of the remaining values as None. However, MaybeUninit<bool> could, by definition, have any bit pattern, so the same optimization is not possible there.