In order for an object o to be an element in a constant set, o must have primitive equality. Similarly, if o is used as case e in a switch statement where e evaluates to o, o must have primitive equality.

In general, we require that an object must have primitive equality in order to be used in a constant expression in a manner where equality must be tested.

However, the exception (for historical reasons) is operator == itself!

This issue is a proposal to generalize the rule about operator == such that it also relies on primitive equality. We would change the language specification from

An expression of the form \code{$e_1$\,==\,$e_2$} is potentially constant
if $e_1$ and $e_2$ are both potentially constant expressions.
It is further constant if both $e_1$ and $e_2$ are constant and
either $e_1$ evaluates to an object that is an instance of
\code{int}, \code{double}, \code{String}, \code{bool} or \code{Null},
or if $e_2$ evaluates to the null object (\ref{null}).

to something like this:

An expression of the form \code{$e_1$\,==\,$e_2$} is potentially constant
if $e_1$ and $e_2$ are both potentially constant expressions.
It is further constant if both $e_1$ and $e_2$ are constant, and
$e_1$ has a primitive operator \lit{==}
(\ref{theOperatorEqualsEquals}),
or $e_2$ evaluates to the null object (\ref{null}).

Note that this proposal implies that enum values can be used as operands to == in a constant expression, cf. #312.

@leafpetersen, @lrhn, @stereotype441, @munificent, @natebosch, @jakemac53, WDYT?