Negative information in type inference not used

[Adam-Vandervorst]

Compiler version

3.0.2

Minimized code

val a: String = (_.toString)(1)

Output

Missing parameter type

I could not infer the type of the parameter _$1 of expanded function:
_$1 => _$1.toString.

Expectation

Work like

val a: String = (1).toString

so being automatically expanded to

val a: String = ((x: Int) => x.toString)(1)

---

I realize something this basic is likely a choice or something that behaves poorly in complex examples.
Nevertheless, this happens a lot, so I think it's worth discussing.

[smarter]

Moving to the feature request repo, is there a practical usage for this?

[Adam-Vandervorst]

That makes sense.

The code that triggered this question was:

  ...
  case App(e1, e2) => EM(m_var, m_app.updatedWith(e1)((_.updatedWith(e2)(f)).liftXT))

which doesn't compile because of the above limitation.
The alternative code is:

  ...
  case App(e1, e2) => EM(m_var, m_app.updatedWith(e1)(((m2: ExprMap[V1]) => m2.updatedWith(e2)(f)).liftXT))

which reveals a lot less of the structure due to the expanded function and type signature.

---

Scala 3 has much better syntax for enum's and extension methods and improves typeclasses.
This moves a lot of functionality typically in functions to these constructs, which all use the method notation.
And with the method notation, comes _.method to abstract over the entity.

---

For the following examples, this is very rare:

extension [A, B, T](pf: PartialFunction[(A, B), T])
  inline def swap: PartialFunction[(B, A), T] = (b, a) => pf(a, b)
  inline def bidirectional = pf orElse pf.swap

Because you're not likely to map over a container of binary partial functions.
However, for this example, the usage is closer to 50/50:

extension [A](as: Iterable[A])
  def forallPairs(p: (A, A) => Boolean) =
    as.forall(x => as.forall(y => p(x, y)))

Because reducing a nested iterable to an iterable of booleans with a known collections is about as likely as it is with a known binary function.