Infer the type of `x` in `val f: (Int => Int) | Unit = x => x + 1`

[smarter]

Or more generally, try harder to infer function literal parameter types from expected type which are unions. The | Unit usecases matters particularly for scala.js where it's not uncommon for a parameter type to be written that way (because Unit corresponds to undefined in scala.js) but I assume that the explicit nulls language feature could run into the same sort of issues.

[smarter]

Here's an example of how this affects -Yexplicit-nulls, without it the following work:

object Test {
  val x = new java.util.ArrayList[Int]()
  val y = x.stream().filter(s => s < 1)
}

bu if we enable it, even if we add the required nn, parameter type inference fails:

object Test {
  val x = new java.util.ArrayList[Int]()
  x.stream().nn.filter(s => s < 1)
}

-- [E081] Type Error: try/i11694.scala:5:23 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5 |  x.stream().nn.filter(s => s < 1)
  |                       ^
  |                       Missing parameter type
  |
  |                       I could not infer the type of the parameter s.

@noti0na1 would you be interested in working on this?

[olhotak]

The argument against doing this for union types in general is efficiency: it requires backtracking.

How do we decide which specific cases to do it for? Only T|Null and T|Unit specifically? Or something more general like T|U where U is simple in some sense? How about Null|T and Unit|T?

[smarter]

I wasn't envisioning something that would require backtracking, I would tweak decomposeProtoFunction to recurse into union types, stopping as soon as it finds a function in one. Anything more complicated involving combining information from multiple branches of the union doesn't seem worth it.

[noti0na1]

@smarter I can work on this. I think finding the leftmost function type/SAM in the union type would be enough.

[LPTK]

Wouldn't this make type inference less reliable? Changing the order in a union could break code, which is not very nice.

IIRC think there is precedent for changes in semantics based on the order of unions and intersections, as they may change erasure. But breaking type inference seems like a usually much bigger problem than changing the erasure of something.

So why not find all function types in all branches and merge them?

[sjrd]

I agree with @LPTK. Anything that is not symmetrical will be very volatile.

To avoid backtracking, consider going through the list of elements of the union and throw away the ones that are not SAM types. If you're left with 1, all good, otherwise abandon.