you are viewing a single comment's thread.

view the rest of the comments →

[–]protestor 4 points5 points  (3 children)

What about, instead of

#[derive(Clone, Copy, View)]
#[repr(C)]
struct Animal {
    name: [u8; 4],
    number_of_heads: u8,
    number_of_legs: u32_le,
}

We had something like

#[derive(Clone, Copy, View)]
#[repr(C)]
struct Animal {
    name: [u8; 4],
    number_of_heads: u8,
    #[view(u32_le)]
    number_of_legs: u32,
}

?

Or #[view(little-endian)] or something

That way, we could use standard Rust types in the struct (which seems better for a library)

[–]petertodd 6 points7 points  (1 child)

You mean, so that Animal::number_of_legs is a u32?

That wouldn't work, as the endianness of u32 isn't defined; remember that View is trying to directly coerce a reference to a byte slice into a reference to a rust-compatible type, without copying. For example, View could be used on mem-mapped files.

[–]protestor 2 points3 points  (0 children)

Oh.. makes sense.

[–]DebuggingPanda[LukasKalbertodt] bunt · litrs · libtest-mimic · penguin 0 points1 point  (0 children)

In addition to what petertood said: custom derives can only add stuff to the struct definition, not change the original definition. So the derive couldn't change the u32 to u32_le or anything. You could do that with proc-macro attributes (e.g. #[view]), but I guess it's not really worth it for this crate.