Skip to content

Should concrete inline methods be effectively final? #8564

Closed
@odersky

Description

@odersky

In #8543 we align static and dynamic semantics of inline methods and allow inline methods to implement abstract methods.

There is one exception where static and dynamic semantics still differ: inline methods can override other inline methods. Example:

class A:
  def f: Int
class B extends A:
  inline def f = 1
class C extends B:
  override inline def f = 2

val b: B = C()
b.f  // gives 1, since dispatched statically
val a: A = b
a.f  // gives 2, since dispatched dynamically

051039e tried to close this loophole by disallowing overriding of concrete inline methods. But it breaks ScalaTest. See the discussion in #8543 for why this is the case.

So, should we disallow this and require code that uses the pattern to be refactored? It might be cleaner in the end but could be painful to get there.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions