On Mon, 20 Nov 2023 17:13:47 GMT, Jonathan Gibbons <j...@openjdk.org> wrote:
>>> For better or worse, every enum exposes its constants' declaration order.
>>> That order may unexpectedly become relied upon elsewhere, and the author of
>>> the enum cannot do anything about it. T
>>
>> Since any `enum` implements `Comparable`, it is not reasonable to say that
>> the order may be relied on "unexpectedly". It is an intentionally defined
>> feature of the language design. And the author _can_ do something about
>> it: the author can choose not to reorder constants when the order is
>> significant.
>>
>> A more interesting design, back in the day, might have been to make
>> `Comparable` an opt-in super type, but that's 20-20 hindsight and not the
>> case.
>
> While it is not _necessary_ to indicate that an enum implements `Comparable`,
> it is permissible to state it explicitly, such as in `enum Foo implements
> Comparable<Foo> { foo1, foo2 }`. which is a somewhat more linguistic way of
> writing `/** The order of the constants is important. */ enum Foo { foo1,
> foo2 }`
> Since any `enum` implements `Comparable`, it is not reasonable to say that
> the order may be relied on "unexpectedly".
What I mean is that not every enum client uses `compareTo()` or `values()[0]`
and `values()[values().length - 1]` to get the opposite extremes of a certain
enum class. Not every client uses `EnumSet.range`. However, given enough time,
they likely, eventually will.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16714#discussion_r1399519679
