Should wasm_parser and wasm_encoder share the same representation?

[taybenlor]

I've been working with wasm_parser and wasm_encoder from Rust, and I noticed that while many of the types are the same (or very similar) they are defined as separate types. This makes it difficult to take a piece of data from wasm_parser and plumb it straight into wasm_encoder.

Should they share the same types internally?

If so, I'd be interested in contributing to making this possible.

[alexcrichton]

It's true yeah. The main reason for the difference is that the two crates have a very different history, but you're definitely not the first to run into this. Awhile back we started adding conversions in the wasm-encoder crate (behind a feature flag) to convert from wasmparser types to wasm-encoder types, but that's more of a band-aid than anything else.

To some degree it would be nice to have a shared type hierarchy here, but it's also somewhat difficult to do. Many pieces have pretty different representations so it's not so easy as "just copy all the stuff to a shared crate and have both depend on it". That being said I don't think it's impossible either, it's just not something that's been fully attempted historically I think.

I think it'd be reasonable to give this a stab, but I don't think it's certain that we'd want to merge the work. Instead I'd at least want to evaluate the results and decide from that whether it's worth it. To be clear I don't think that this is a bad idea, but at the same time I also don't know that it's a guaranteed-to-be-good idea, which is why I'd want to evaluate the results myself at least.

[taybenlor]

From your point of view, what would taking a stab look like? What level of detail would you want to see?

Also in terms of implementation I can see a few different pathways for making this work:

• Create a third representation and implement From/Into to get between each form

• Try and reimplement one side (either parser or encoder) in terms of the other's types

• Make a crate with helpers that convert between the two (no third representation)

Do you have a particular approach in mind?

[alexcrichton]

I haven't given this too too much thought so I don't know exactly where things would end up or what it would look like, so I can't necessarily give a concrete answer.

What I can say though is that having two representations is probably already too much so I'd prefer to avoid adding a third. What I might recommend instead is to take common types in wasmparser/wasm-encoder, one at a time, and pull the "union" of the two representations into a new crate that both wasmparser/wasm-encoder depend on. Something like wasm-tools-types or similar. That would enable an incremental approach to doing this over time, and it might make sense to start with some small-ish types to start and see how it plays out?

[taybenlor]

That makes a lot of sense! I think maybe ValType is a good place to start, but I'll see once I dive in. Might be used in too many places.