Proposal: Add areCasesEqual Functionality to allow for comparing cases while ignoring their associated values

[vladyslavsosiuk]

Summary
I would like to propose adding a utility function, areCasesEqual, to the library to simplify and enhance the comparison of enum cases. This functionality leverages CasePathable and CasePathReflectable to determine if two enum cases are equal, regardless of their associated values. This can be particularly useful in scenarios where enums with associated values need to be compared by their case type alone.

Problem Statement
Currently, comparing enum cases with associated values requires custom logic or boilerplate code to ignore the associated values and focus solely on the case type. This can lead to repetitive code and potential errors when maintaining large enums. Also such custom logic doesn't always guarantee exhaustive implementation.

For example:

enum ExampleEnum: Equatable {
    case caseA(Int)
}

let case1 = ExampleEnum.caseA(1)
let case2 = ExampleEnum.caseA(2)

// Comparing cases requires custom logic to ignore associated values
let areCasesEqual = case1.is(\.caseA)  == case2.is(\.caseB)

Proposed Solution
Introduce a static function, areCasesEqua, as an extension to CasePathable. This function will compare two enum cases by their case type, ignoring associated values.

Here is the interface:

extension CasePathable {
    public static func areCasesEqual(_ lhs: Self, _ rhs: Self) -> Bool { ... }
}

Example Usage

enum ExampleEnum: CasePathable {
    case caseA(Int)
}

let case1 = ExampleEnum.caseA(1)
let case2 = ExampleEnum.caseA(2)

let areEqual = ExampleEnum.areCasesEqual(case1, case2) // Returns true

Request for Feedback
If this proposal is accepted, I would be happy to work on a PR implementing this functionality.

[stephencelis]

@vladyslavsosiuk The library currently ships with this functionality:

ExampleEnum.allCasePaths[case1] == ExampleEnum.allCasePaths[case2]

Does this satisfy your needs? Anything we could do to improve documentation and discoverability?

[vladyslavsosiuk]

Hi @stephencelis,

Thank you for the response. The code you shared would be the implementation of the proposed function. What the suggested areCasesEqual function brings to the table is the ability to use it in a point-free style, making it more concise and reusable in scenarios where a predicate is required.

For example:

func doSomething<T>(_ values: [T], predicate: (T, T) -> Bool) -> [T] {...}
@CasePathable
enum ExampleEnum {
    caseA(Int)
}
// Without the proposed function:
doSomething([ExampleEnum.caseA(1), .caseA(2)]) {
    ExampleEnum.allCasePaths[$0] == ExampleEnum.allCasePaths[$1]
}

// With the proposed function:
doSomething([ExampleEnum.caseA(1), .caseA(2)], predicate: areCasesEqual)

[stephencelis]

Thanks for sharing an example! One nice thing is that you can define the helper outside the library and use it in your application code today. With that you can maybe build up a collection of motivating examples to show that the helper deserves to be in the library?

We tend to be conservative in expanding the core API surface area unless an API can fulfill an unfulfilled need, so I think we will hold off for now unless you want to expand your proposal with more motivation. Either way, thanks for sharing the helper and for the discussion!

[vladyslavsosiuk]

Fair enough. While trying to write an example, I realized there was a better way to solve the problem without needing the predicate. So indeed, there is no motivating example at this time. Thanks for the discussion and feedback!