Skip to content

EnumString macro ignores parse_err_ty when there is a default variant #430

@scovich

Description

@scovich

Related to #307

In theory, this new feature of EnumString should allow infallible parsing of an enum with a default variant:

The default error type is strum::ParseError. This can be overridden by applying both the parse_err_ty and parse_err_fn attributes at the type level. parse_error_fn should be a function that accepts an &str and returns the type parse_error_ty.

(aside: there are some stray references to parse_error_fn and parse_error_ty)

Unfortunately, #380 that added the feature explicitly sets the error type back to strum::ParseError if the enum has a default variant, see here.

Thus, the following:

#[derive(EnumString)]
#[strum(
    parse_err_fn = not_needed_because_parsing_is_infallible,
    parse_err_ty = std::convert::Infallible,
)]
pub enum InfallibleEnum {
    Foo,
    Bar,
    #[strum(default)]
    Unknown(String),
}

fn parse_infallible(s: &str) -> Result<InfallibleEnum, std::convert::Infallible> {
    s.parse()
}

fails to compile with:

error[E0271]: type mismatch resolving `<InfallibleEnum as FromStr>::Err == Infallible`
  --> test.rs:24:7
   |
24 |     s.parse()
   |       ^^^^^ expected `ParseError`, found `Infallible`

For more information about this error, try `rustc --explain E0271`.

Perhaps this was just an oversight in the original PR? Or is there a specific (but undocumented) reason it's important for enums with default variants to ignore the custom error type specification?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions