Naming problems

[frol]

I wonder how you manage the non-descriptive names like as_static, as_ref, when you have an enum that, e.g. describes a state:

enum MyState {
    Position1(i32),
    GameOver(String),
}

Having my_state.as_ref() or my_state.as_static() looks odd to me when I really want to express my_state.as_variant_name(). Currently, I have to write a 4-line wrapper around as_static just to make my API sane, but I still have a confusing AsStaticRef implementation in the documentation.

This is a small papercut, but I still want to bring it in.

I would prefer having AsEnumVariantName trait with as_enum_variant_name or as_variant_name method.

[Peternator7]

Sorry I didn't respond sooner; I've been thinking about this comment for a while now, and I tend to agree, I'm just looking for a good time to make the change because it will be rather disruptive I'm sure.

[frol]

May I suggest introducing new traits and method names while keeping the old ones as aliases? So then the old names can be promoted to the deprecation and the future breaking-change release would just remove the old names altogether.