-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Should concrete inline methods be effectively final? #8564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
For the ScalaTest use case, @smarter proposed two likely alternatives at #8543 (review). 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 #8543 (review), performing the stattic dispatch in a single macro as in #8601 or defining the |
Extensions methods do not apply to implicit |
Fix #8564: Make concrete inline methods final
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:
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.
The text was updated successfully, but these errors were encountered: