Imported From: https://issues.scala-lang.org/browse/SI-2487?orig=1
Reporter: Avi Pfeffer (apfeffer)
Attachments:

• issue.txt (created on Oct 19, 2009 1:17:06 PM UTC, 24593 bytes)

@paulp said:
Ah, the old define a recursive method in a block as part of a superconstructor argument trick. Similar in some ways to #1909, in that it taxes the lifting abilities a bit too far.

@odersky said:
Here's a simpler example which makes this fail:

class A(x: Int)

object B {
  def bar(n: => Int) = n
}

class B extends A ({
  def foo(n: => Int): Int = if (n == 0) 1 else B.bar(foo(n - 1))
  foo(10)
})

The problem is the recursive call to class foo in the anonymous class that's created
for bar's call by name parameter. To resolve that call lambda lift tries to find member foo' of B. But since foo' is defined in the constructor, it is not a member of `B'.

@paulp said:
Replying to [comment:6 odersky]:

The problem is the recursive call to class foo in the anonymous class that's created
for bar's call by name parameter. To resolve that call lambda lift tries to find member foo' of B. But since foo' is defined in the constructor, it is not a member of `B'.

To my naive eye it looks like always lifting functions defined inside constructor or super calls into the companion object rather than the instance would solve this issue. As I understand it, that was the solution to #1909. If methods defined in these places can't reference "this" anyway since it doesn't exist yet, what is lost by making it static?

@paulp said:
Closing as a duplicate of #6666 because it has a cooler number.

@SethTisue said:
the ticket is still open?

@paulp said:
Right, I was just telling you something I'd do someday. Oh look, today is the day. Thanks.