Reexport yaxpeax-arch

[i509VCB]

Since Instruction::len() requires importing a trait from yaxpeax-arch and the arch crate is a required dependency it may make sense to reexport yaxpeax-arch inside of this crate and the other architecture crates.

Reexports would involve adding a pub use yaxpeax_arch; statement to the lib.rs. Adding an as <whatever> as suitable to make sense in the crate structure.

This would allow users to not have to explicitly declare yaxpeax-arch in their Cargo.toml's dependencies while still being able to use the arch types.

[iximeow]

this seems like good advice for any implementors of yaxpeax-arch, yeah. it might also make sense to re-export num_traits::Zero or at least provide functions like zero() and one() on Address

Adding an as <whatever> as suitable to make sense in the crate structure.

i'm not sure i follow. pub use yaxpeax_arch; ought to allow users to write use yaxpeax_x86::LengthedInstruction and call Instruction::len() without thinking about the actual yaxpeax-arch crate. is there a renaming that would make sense to you?

(as an aside, this issue has me rethinking the idea that an instruction could not have a len(). it seemed like a less safe requirement before the Reader trait, now a ptrdiff_t-style number of words is more clearly expressible.)

[i509VCB]

Hmm how to approach that is a good question.

You could introduce a sort of prelude module to yaxpeax-arch and just reexport the contents of the prelude in yaxpeax-x86 to avoid needing to declare imports using yaxpeax_x86::yaxpeax_arch::LengthedInstruction.

With the prelude contents being reexported, users would just use use yaxpeax_x86::LengthenedInstruction