Idiomatic way of handling non exhaustive enum variant construction

[minor tide]

I'm writing a test framework, and I want to expose a TestEvent enum as part of the public API for output formatters to use. The enum itself should be #[non_exhaustive], because I might want to add new events in the future, thats easy enough to deal with. The problem I'm having is making the variants themselves #[non_exhaustive], I've made the public API its own crate to keep things organised, but that means everything using these enums can't construct the enum variants. Is there a nice way to handle that?

With non exhaustive structs, its possible to just provide a new method and modify fields as needed, but I'm not sure how to do the same on an enum because modifying fields would require pattern matching which would be quite clunky to do immediately after calling a constructor method.

[polar carbon]

Sounds like you could make a struct for each variant, and then construct those as needed before putting it into the enum.

[chilly valley]

it's not unheard of to provide a separate constructor function for each variant