Dotty: Should concrete inline methods be effectively final?

Created on 17 Mar 2020  路  6Comments  路  Source: lampepfl/dotty

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.

language enhancement question

Most helpful comment

Inline methods should be final as it is the only sound option.

All 6 comments

Inline methods should be final as it is the only sound option.

To people downvoting this issue: please provide a concrete example/use case where the ability to override is exploited, so that we can propose alternatives and/or debate.

There's the original usage in ScalaTest, which i believe is entirely acceptable, especially because you're unlikely to upcast this to access a different version of the method. Maybe we could consider an exemption for protected methods

For the ScalaTest use case, @smarter proposed two likely alternatives at https://github.com/lampepfl/dotty/pull/8543#pullrequestreview-374820311. The first one being more hacky but with no refactoring needed, and the second one being a better overall design but requiring more refactoring.

The ScalaTest use case can be encoded using @smarter suggestion in https://github.com/lampepfl/dotty/pull/8543#pullrequestreview-374820311, performing the stattic dispatch in a single macro as in #8601 or defining the assert as an extension method on Assertions and another on Diagrams.

@nicolasstucki

defining the assert as an extension method on Assertions and another on Diagrams.

Extensions methods do not apply to implicit this, you'd be able to call assert only as this.assert if it's an extension method

Was this page helpful?
0 / 5 - 0 ratings

Related issues

m-sp picture m-sp  路  3Comments

noti0na1 picture noti0na1  路  3Comments

NightMachinary picture NightMachinary  路  3Comments

odersky picture odersky  路  3Comments

fommil picture fommil  路  3Comments