Trial balloon: Make default getters final

[odersky]

I want to see what the fallout is when we make default getters final, which is necessary if we want to make them inlineable.

So far I have seen ~20 occurrences in the compiler codebase itself and a handful more in the tests where an overriding function has exactly the same default argument as the overridden function, so the repeated default argument was redundant.

I have seen no occurrences in this codebase where the overriding function had a meaningful different default argument, except for tests that were specifically designed to test that feature.

[sjrd]

As I mentioned off-line a while ago, this is going to be problematic for Scala.js. A typical use case is the following:

@js.native @JSGlobal("NativeParent")
class NativeParent extends js.Object {
  def foo(x: Int, y: Int = js.native): Int = js.native
}

class NonNativeChild extends NativeParent {
  override def foo(x: Int, y: Int = 5): Int = x + y
}

Since default values are handled at callee site for JS classes, the NonNativeChild must provide a new default value for y. It cannot "inherit" the default value from its parent, since it would only be in the body of NativeParent.foo.

We test this in NonNativeJSTypeTest.overrideMethodWithDefaultValuesFromNativeJSClass (among many other tests for default values).

Note that for this to work, we don't actually need late binding of the default method calls. They are called from within the generated body of foo, not from the call site. So enforcing early binding without preventing overrides would be OK for this to work.

[odersky]

Note that for this to work, we don't actually need late binding of the default method calls. They are called from within the generated body of foo, not from the call site. So enforcing early binding without preventing overrides would be OK for this to work.

Of course in general, going from late to early binding is a behavior change, so we have to be very careful here. Can we find criteria that tell us that the change is OK and we should still accept the override?

Besides ScalaJS I was thinking to allow overrides if the two default argument expressions are the same since that seems to be a common case. Maybe warn but don't reject.

[sjrd]

Can we find criteria that tell us that the change is OK and we should still accept the override?

The criteria for the Scala.js-specific use case is whether the enclosing class extends js.Any. In other words, whether ctx.settings.scalajs.value && ownerClass.isJSType is true.