PROPOSAL: Equivalence operators (formerly titled

Mark Thornton mthornton at
Sat May 9 01:33:27 PDT 2009

Derek Foster wrote:
> Hi, Mark.
> Thanks for your comments.
> The proposal already does what you suggest, although I agree it is not clear from the section you quoted (which was only intended to be a brief feature summary). If you look in the specification section, you will find that in a case like "a < b" where a is Float and b is float, that since both types are convertible to a primitive type, that this conversion will be done before the operation is attempted (possibly triggering a NullPointerException on unboxing), yielding the same results as would occur in Java now.
> In some ways, I think it would be nice to have the ># and <# operators return true if both of their operands are null, even if both operands are typed as boxed primitives. This would be more similar to how ## and !# work and would be consistent for all operators if you assume that null "is equivalent to" null. I am considering changing the proposal to allow this. (Currently this operation would provoke a NullPointerException during unboxing, according to proposal version 3 and before). < and > would not be affected by this, of course. Comments?
> Derek
My first thought was that managing null with ># and <# was attractive 
and nicely consistent with ## and #!, but then <, > don't just return 
false but throw a NullPointerException.

Why can't we overload >= and <= instead in the same way as < and > (i.e. 
only apply to Comparable types which are NOT convertable to primitives).
##, #! handle null, based on equals()
<=, >=, <, > For primitives or primitive wrappers behave as now and 
throw NullPointerException with null wrapper values
<=, >=, <, > For Comparable types other than primitive wrappers, based 
on compareTo, throw NullPointerException

Mark Thornton

More information about the coin-dev mailing list