null == operand causes ambiguous feature call error.

[gallandarakhneorg]

I have defined several extension methods (which are implicitly imported):

def boolean operator_equals(AtomicLong left, int right) {}
def boolean operator_equals(AtomicLong left, short right) {}
def boolean operator_equals(AtomicLong left, long right) {}
def boolean operator_equals(AtomicLong left, float right) {}
def boolean operator_equals(AtomicLong left, double right) {}
def boolean operator_equals(AtomicLong left, byte right) {}
def boolean operator_equals(AtomicLong left, Number right) {}
def boolean operator_equals(AtomicInteger left, int right) {}
def boolean operator_equals(AtomicInteger left, short right) {}
def boolean operator_equals(AtomicInteger left, long right) {}
def boolean operator_equals(AtomicInteger left, float right) {}
def boolean operator_equals(AtomicInteger left, double right) {}
def boolean operator_equals(AtomicInteger left, byte right) {}
def boolean operator_equals(AtomicInteger left, Number right) {}

The following lines are compiled without error:

def void fct(AtomicInteger value) {
  if (value == null) {
  }
}

But, the following lines cause a compilation error (ambiguous feature call):

def void fct(AtomicInteger value) {
  if (null == value) {
  }
}

As you could see, the operands of the == operator are switched.
Semantically, both definitions are equivalent.
Both should compile without error.

[gallandarakhneorg]

My question is: what is the best way to support the failing case?

Is possible to define an operator_equals function and specifying that this function is usable when the left argument is null?

Should I define operator_equals(Object left, Number right)? In this case, the type compiler of Xbase hould be fixed to avoid the ambiguous feature call error.

[cdietrich]

@szarnekow any idea?

[szarnekow]

To me the declaration is indeed ambigous. Can you answer the question, which extension method should be called for null == myAtomicInteger and why?

[gallandarakhneorg]

For me it should be operator_equals(Object, Object).
The null value has any type, and in this case it could be assumed to have the Object type safely.
This assumption is valid only for null.

Of course the question becomes more complex if you consider that operator_equals(Object, Number) is defined. It could have a higher priority than the previous method.
Note that when the operator_equals(Object, Number) is defined, it is not considered within the list of the ambiguous calls (according to the error message).

[szarnekow]

What does Java do if you have three static imports for your extension methods and the overload for Object, Object?

[gallandarakhneorg]

If there is multiple function with a right parameter with type Number, Java compiler also generates an error: The method operator_equals(AtomicInteger, Number) is ambiguous for the type TestTool2.

I think we could keep the error message from Xbase (this is not the problem at all), but with a small change into the text for this special case. We could add into the error message something like: "We recommend to use the operator === when the left operand is null"?

What do you think?

[szarnekow]

I'm not totally keen on having a special case for one scenario because the (expected and correctly detected) ambiguity is present to other operators and extension methods, too.

[cdietrich]

Closed as wont-fix. Feel free to reopen at github.com/eclipse/xtext