Implementation restriction: polymorphic function literals must have a value parameter

[Swoorup]

Compiler version

3.1.3

Minimized code

enum CounterInput[Response]:
  case Inc extends CounterInput[Unit]
  case Dec extends CounterInput[Unit]
  case Get extends CounterInput[Int]

def counterBehaviorK[O]: (Int, CounterInput[O]) => (Int, O) =
  case (s, CounterInput.Inc) =>
    (s + 1, ())
  case (s, CounterInput.Dec) =>
    (s + 1, ())
  case (s, CounterInput.Get) =>
    (s, s)

// not sure how to pass this behavior parameter
def doSth[S, I[_]](behavior: [O] => (S, I[O]) => (S, O)) = println("Hi")

doSth[Int, CounterInput]([O] => counterBehaviorK[O]) // Implementation restriction: polymorphic function literals must have a value parameter
doSth[Int, CounterInput](counterBehaviorK)  // Also error

Scastie: https://scastie.scala-lang.org/7dElqAKNQme6XFWEYckzhA

Output

Implementation restriction: polymorphic function literals must have a value parameter

Expectation

Compiles successfully

[Jasper-M]

I don't think any type inference or eta-expansion is implemented yet for polymorphic function values. You have to be very explicit:

doSth[Int, CounterInput]([O] => (i: Int, c: CounterInput[O]) => counterBehaviorK(i, c))

[Swoorup]

I don't think any type inference or eta-expansion is implemented yet for polymorphic function values. You have to be very explicit:

doSth[Int, CounterInput]([O] => (i: Int, c: CounterInput[O]) => counterBehaviorK(i, c))

Ah makes sense. That explains #15554 too then.

[prolativ]

Closing the issue then as this is not a bug but a known lack of feature

[jivanic-demystdata]

Is this not implemented yet? I'm using Scala 3.5.2 and I hit this exact issue
If not implemented yet, shouldn't we re-open this ticket so we can track the changes in this subject?

Cc @guizmaii

[bishabosha]

@smarter and @Sporarum did various wip on this

[Sporarum]

Our work can be found in SIP-47:
https://github.com/scala/improvement-proposals/blob/main/content/polymorphic-eta-expansion.md

[SethTisue]

Neither "completed" nor "not planned" is exactly right, but "not planned" seems a bit closer, since the planning is happening in the SIP process, not here. (We don't normally keep open tickets for feature requests; this is primarily a bug tracker.)