infer anonymous fun parameter type from usage

As suggested by @jensli in #7351, we could enhance anonymous function parameter type inference to take usages into account. For example, in:

(n) => Integer.format(n, 16)

The parameter n would be inferred to have type Integer.

Quoting myself:

If the parameter is only used as a function argument, and never:

• as the receiver of a method invocation, nor
• in an operator expression, nor
• as the argument of an overloaded (Java) method,

then we could reasonably infer its type from how it’s used.

[gavinking]

I realized that we can also do some good stuff with some operator expressions, for example:

Float(Float) f = (x) => x/2.0;
Boolean(Float) g = (x) => x>2.0;
Boolean(Boolean,Boolean) h = (p,q) => !p || q;

I’ve implemented this sort of inference for the operators:

+ - * / % ! || && ** .. < > <= >= <=> == != === = += -= *= /= %= ||= &&=

[someth2say]

@gavinking

The question I have is whether stuff like the following should be accepted or rejected:

Why shouldn’t both be accepted? format(n,...) implies n should be Integer, and format(n+100... implies n should be Summable (or Numeric, not sure…) In any case, the union for both restrictions (Integer & Summable) should generate the same type (Integer), that is the right type for n, isn’t it? As long as union is commutative, the order of restrictions should not matter, IMHO.