# SE-0266 — Synthesized  Comparable  conformance for enum types

**URL:** <https://forums.swift.org/t/se-0266-synthesized-comparable-conformance-for-enum-types/29457>\
**Category:** Proposal Reviews\
**Created:** [October 2, 2019, 12:01am UTC](https://forums.swift.org/t/se-0266-synthesized-comparable-conformance-for-enum-types/29457 "2019-10-02T00:01:34Z")\
**Posts on this page:** 1\
**Showing post:** 75

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [October 15, 2019, 2:32pm UTC](https://forums.swift.org/t/se-0266-synthesized-comparable-conformance-for-enum-types/29457/75 "2019-10-15T14:32:19Z")

</div>

> [@David\_Sweeris](#):
>
> > So whether or not people "care", it's a property that people can rely on if they wish. Given that `Comparable` and `CaseIterable` both effectively would define total orders among the cases, I think it would be _actively harmful_ for those orders to be _different._
> 
> Oh, my mistake, I hadn't realized that the order for that was documented behavior. Also, I agree that it would be bad if they were ordered differently.

Late to the party, but this brings up a potential footgun not discussed yet:

If the user has elected to provide a custom implementation of `CaseIterable` conformance, potentially reordering the cases, then it can be unexpected if `Comparable` is synthesized using source order, introducing two (or if `RawRepresentable`, potentially three) definitions of total order among cases without warning.

It may be reasonable to consider _not_ synthesizing `Comparable` for enums with custom `CaseIterable` implementations.

---

_[View the full topic](https://forums.swift.org/t/se-0266-synthesized-comparable-conformance-for-enum-types/29457)._