You can't, without specialization (which is far from being stabilized, since it's unsound as-is). A type variable T matches all types, including Vec<T>.
Rust does not offer ways for “more specific” implementations to override “less specific” ones. There’s a long-time-unstable feature called “specialization” which aims to achieve this, but it’s hard to pull off in a satisfying and sound manner.
Regarding the specific code at hand, I cannot really imagine sound use-cases though where you couldn’t just either manually pick the appropriate one of these two unsafe functions, or write a more specific set of impls for those types that you actually do use, but feel free to educate about your use-case, in case that’s impossible there, and I’ll gladly point out any soundness issues I can find
Thanks for the information,
Take a quick look on bytemuck, seems like Pod trait is need to be implemented for the casting types, which is not quite fit my need. Types I want to cast from bytes are defined by other crate, I can't implement Pod for those types
That is a very C-like risky design pattern that Rust tries hard to avoid. It can't work for arbitrary types, they must be compatible, so it is expected that they will opt in somehow:
Layout of Rust-native types is not guaranteed. Order of struct fields may change, may even be randomized. Layout of tuples is undefined. Only #[repr(C)] types have a stable layout.
Arbitrary types could contain pointers, which won't make any sense after sitting on disk. Some Rust types have forbidden bit patterns that are UB, e.g. you must never ever allow enum to contain a value out of range or store 2 in bool. Loading arbitrary bytes from disk doesn't let you control for this.
To use this trait you first need to get a properly initialized instance of that type. You'll need to rely on another trait like Default to do this. It's not safe to cast arbitrary buffers, not even zeroed memory, to make an instance of an arbitrary Rust type. For reading you probably should use MaybeUninit<T> instead.
In Rust-idiomatic code, foreign types usually implement something like serde Deserialize, which then can be safely used with any representation. For serde there's bincode which is pretty fast and close to being a memory dump of a struct, but it guarantees to be safe and portable.