Feature request and issues with naming on EnumIs and EnumTryAs.

[13k]

Request

Currently, EnumIs and EnumTryAs generate methods with a simple snake case transformation from variant names.

It would be nice to customize generated method names, since some snake case rules could look awkward, both from heck and the customized snakify:

#[derive(strum::EnumIs, strum::EnumTryAs)]
enum E {
    // generates `is_int_64()` and `try_as_int_64*()`
    // I'd like to generate `is_int64()` and `try_as_int64*()`
    Int64(i64),
    // generates `is_c_string()` and `try_as_c_string*()`
    // I'd like to generate `is_cstring()` and `try_as_cstring*()`
    CString(CString),
}

Initially I thought of suggesting overriding names using serialize attribute since it would be easier to implement but not only it would break existing code, it is also semantically incorrect (display representation used as method name).

So I guess the only option is to add yet another macro attribute specifically for this use case.

Naming issues

On the topic of being semantically correct, I got a bone to pick with EnumTryAs specifically, because it doesn't follow naming conventions.

The generated name prefix for the method that takes self (move) doesn't follow clippy's naming convention. try_as_* implies taking &self as the receiver. For moves, it should be try_into_*.

If try_into_*(self) -> Option<T> is generated, then try_as_*_ref(&self) -> Option<&T> could drop the _ref suffix to try_as_*(&self) -> Option<&T>.

Another point, but this one is bikeshedable since it's not a convention, is that try is usually used for fallible operations. None of the generated methods are fallible, so IMO it feels weird to use try_as_variant_ref and match against an Option, or when using the ? operator on try_* methods.

Edit:

For the try "issue", I forgot to add my suggestion to simply drop the try_ prefix.

• into_<variant>(self) -> Option<T>
• as_variant(&self) -> Option<&T>
• as_variant_mut(&mut self) -> Option<&mut T>

Obviously these changes break compatibility. I don't know if adding an entirely new derive with a new name (like EnumAs) that does the same thing would be acceptable, but it wouldn't break compatibility.

[13k]

I'd also like to point out that the snake case rules are inconsistent between EnumIs/EnumTryAs and all other display representation derives (Display, AsRefStr, IntoStaticStr, EnumString, VariantNames):

use strum::*;

#[derive(EnumIs, EnumTryAs, Display, AsRefStr, IntoStaticStr, EnumString, VariantNames)]
#[strum(serialize_all = "snake_case")]
enum E {
    // methods use `i_32`
    // string reprs are `"i32"`
    I32(i32),
    // methods use `c_str`
    // string reprs are `"c_str"`
    CStr(String),
}

// VARIANTS = &["i32", "c_str"]

Again, these two concepts are semantically different, but it's still strange to have methods and str reprs with different naming conventions when using defaults for both.