forbid using wildcard in pattern matching if it matches some, but not all, of a custom type's variants

[GabrielBoehme13]

What the rule should do:

The rule should report an error when a pattern match contains a wildcard (_ or variable name) that handles some, but not all, of a custom type's variants. Either all of its variants must be listed explicitly, or they must all be matched by wildcard.

(If exceptions are needed for some custom types, this rule would allow them to be specified in a List.)

This is a partial superset of the proposed NoRedundantWildCard rule by @jfmengels – this rule would handle partial pattern matching more broadly, but only for custom types. This rule would also very closely match a suggestion by @Janiczek from that same discussion.

What problems does it solve:

It prevents us from accidentally opting out of the Elm compiler's assistance when a custom type is changed, and ensures that we have the exact list of custom types excluded from that assistance which we'd need to review manually.

Examples of things the rule would report:

type Something
  = A
  | B
  | C


-- B and C are not explicitly matched

disallowed1 : Something -> String
disallowed1 something =
  case something of
    A ->
      "A!"
    _ ->
      "some other option"


-- while Ok and Err are fine, B and C are not explicitly matched

disallowed2 : Result String Something -> String
disallowed2 result =
  case result of
    Ok A ->
      "A!"
    Ok _ ->
      "some other option"
    Err msg ->
      "Error: " ++ msg


-- wildcard captures only some variants from both Result and Something

disallowed3 : Result String Something -> String
disallowed3 result =
  case result of
    Ok A ->
      "A!"
    _ ->
      "some other option or error"


-- wildcard captures all Something variants, but only one Result variant

disallowed4 : Result String Something -> String
disallowed4 result =
  case result of
    Ok _ ->
      "it's ok"
    _ ->
      "it's not ok!!!!"

Examples of things the rule would NOT report:

type Something
  = A
  | B
  | C


-- all custom type variants are matched explicitly

allowed1 : Something -> String
allowed1 something =
  let
    other =
      "some other option"
  in
  case something of
    A ->
      "A!"
    B ->
      other
    C ->
      other


-- all custom type variants are matched explicitly

allowed2 : Result String Something -> String
allowed2 result =
  let
    other =
      "some other option"
  in
  case result of
    Ok A ->
      "A!"
    Ok B ->
      other
    Ok C ->
      other
    Err msg ->
      "Error: " ++ msg


-- all custom type variants are matched explicitly

allowed3 : Result String Something -> String
allowed3 result =
  let
    other =
      "some other option or error"
  in
  case result of
    Ok A ->
      "A!"
    Ok B ->
      other
    Ok C ->
      other
    Err _ ->
      other


-- all custom type variants are matched consistently
-- Result variants are all matched explicitly
-- Something variants are all matched by wildcard

allowed4 : Result String Something -> String
allowed4 result =
  case result of
    Ok _ ->
      "it's ok"
    Err _ ->
      "it's not ok!!!!"

When (not) to enable this rule:

If most of your custom types specify long lists of variants which you regularly pattern match by listing only some of those variants, then you probably won't find this rule very useful.

If you want to guarantee that the Elm compiler can always identify needed code updates after a custom type change – while you keep a list of excluded custom types you've chosen to review manually instead – this would be the rule for you.

I am looking for:

• Feedback
  • Would others find this rule helpful?
  • What's a good name for this rule?
    • NoInconsistentCustomTypeVariantMatching is descriptive, but long
• Someone to implement this rule