Just to reflect some private concerns here: this seems like an extension of new syntax sugar that I know @daxpedda wanted to try and avoid in the core, so I'm going to defer to him for review.

E.g. once we land this, what if users might want all other Serde enum representations built into wasm-bindgen as well? It seems we might want to answer a question of where we draw a line between built-in serialization and things covered by serde-wasm-bindgen integration before adding features from said subset.

There are definitely valid reasons to add some integrations to the core, at least for optimisations alone as serde-wasm-bindgen doesn't have as much access to type information at compile-time as wasm-bindgen itself does, but we need to make sure we don't paint ourselves in the corner and on the hook for maintenance of even larger API area with all the semver difficulties that wasm-bindgen already comes with.

Maybe there are hooks we could expose instead to make tools like serde-wasm-bindgen more efficient or support more types, so that the core remains lean? I don't know the answer, but something worth exploring.

Offtop: what you're adding here is rather the untagged enums not tagged ones.

CodSpeed Performance Report

Merging #4734 will not alter performance

_{Comparing enum-fallbacks (0f9ca45) with main (96f3e1e)}

Summary

✅ 4 untouched