If LittleEndian and BigEndian were empty structs instead of empty enums, I would be able to have dynamic references to them. Then, I could write my code to use the ByteOrder interface, slotting in either LittleEndian or BigEndian once the byte order was determined at runtime. This is useful for certain file formats for which the endian is not known until the file is opened. (Usually these arise when transferring data that was written out in a native format between systems with different endian.)
It seems like it is common to not know what byte order you should be reading until runtime. Perhaps Rust's object system can be used to handle this with the smallest possible change to byteorder.
As always, I am open to other ways of solving this problem.
If LittleEndian and BigEndian were empty structs instead of empty enums, I would be able to have dynamic references to them. Then, I could write my code to use the ByteOrder interface, slotting in either LittleEndian or BigEndian once the byte order was determined at runtime. This is useful for certain file formats for which the endian is not known until the file is opened. (Usually these arise when transferring data that was written out in a native format between systems with different endian.)
It seems that this previous issue was posted by someone who wanted to achieve something like this goal: https://github.com/BurntSushi/byteorder/issues/59
Here is a relevant discussion: https://github.com/BurntSushi/byteorder/issues/95
It seems like it is common to not know what byte order you should be reading until runtime. Perhaps Rust's object system can be used to handle this with the smallest possible change to byteorder.
As always, I am open to other ways of solving this problem.