TypeId should be (u64, u64) instead of u128 to save space

[stepancheg]

On Apple Silicon (unlike x86_64) u128 is 16-bytes aligned. So it takes extra space with little or no benefit. I looked at generated code, it is the same:

https://rust.godbolt.org/z/3sE7sMsjj

(Note just using repr(packed(8)) won't work because it will pass TypeId by reference not by value)

Additionally the issue with current TypeId is that is has different alignment on different platforms. Rust does not provide guarantees about the alignment, but if this was the same everywhere, it'd make life easier. (Practically we encountered this issue when our CI worked fine on Apple x86_64 macs, but the program didn't work on Apple Silicon.)

rustc 1.74.0-nightly (a991861 2023-09-05)
macOS, Apple Silicon

[RalfJung]

Note that (u64, u64) doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.

[cactusdualcore]

Note just using repr(packed(8)) won't work because it will pass TypeId by reference not by value

I might be wrong here, but

let x = 1u128;
{
    let y = x;
    println!("{}", y);
}
println!("{}", x);

seems to work, so I believe u128 is Copy. So can't said problem be eliminated by implementing Copy on TypeId as well?

[stepancheg]

@Cactus-Man TypeId already implements Copy. Also Copy does not affect alignment.

[lygstate]

Note that (u64, u64) doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.

If that's the case, how about (u32,u32,u32,u32)

[stepancheg]

If that's the case, how about (u32,u32,u32,u32)

That would make hashing and probably equality slower.

[lygstate]

If that's the case, how about (u32,u32,u32,u32)

That would make hashing and probably equality slower.

on 32 bit system would not be slower