Consider ergonomics for configuring enum generators without `#[derive(DefaultGenerator)]`

[Liam-DeVoe]

Rust has a feature that python does not: proper tagged unions with associated data in each base type. For example:

#[derive(DefaultGenerator)]
enum A {
    B(u64),
    C(u64, u64)
}

It is natural to want a generator for A, with configuration control over the generator for each of the B, C fields.

In many cases, you can do this with gs::default_generator:

let g = gs::default_generator<A>().B(gs::just(42)).C(gs::just(43))

But what if one of your fields cannot be automatically derived? You can't use #[derive(DefaultGenerator)] anymore, but you still want the nice inline configuration syntax.

How should we address this? We're defining syntactic methods based on arbitrary field names, which I believe precludes the possibility of gs::from_enum(A).B(...).C(...) or similar. The other alternative I can think of is #[derive(EnumGenerator)] (zero thought put into naming), and combine that with gs::from_enum. from_enum panics at runtime if not all fields are configured.

Thoughts welcome.