devlaam
February 5, 2026, 10:52pm
1
This code works:
trait Inner :
def switch: Boolean
inline def go1: String = inline if switch then "Yes" else "No"
def go2: String = if switch then "Yes" else "No"
object Outer extends Inner :
inline def switch: Boolean = true
def test1 = go1
def test2 = go2
println(Outer.test1)
println(Outer.test2)
However, if I move the definition of switch to a trait:
trait Settings :
inline def switch: Boolean = true
trait Inner :
def switch: Boolean
inline def go1: String = inline if switch then "Yes" else "No"
def go2: String = if switch then "Yes" else "No"
object Outer extends Settings, Inner :
def test1 = go1
def test2 = go2
println(Outer.test1)
println(Outer.test2)
it results in an java.lang.AbstractMethodError: Receiver class Outer$ does not define or inherit an implementation of the resolved method 'abstract boolean switch()' of interface Inner. The order of the traits in the object extension does not seem to matter.
Why is this?
1 Like
I think there is a ticket about unsoundness of overriding inline.
I am not in a position to look it up at the moment. (That position would be “upright”.)
Inlines don’t get bodies unless @publicInBinary or similar.
Edit: I guess that is for accessors to privates. Maybe there is a different mechanism for retaining the bytecode.
main ← dotty-staging:add-binaryAPI-annot
opened 02:42PM - 15 Aug 23 UTC
Introduces [SIP-52](https://github.com/scala/improvement-proposals/pull/58) as a… n experimental feature.
Fixes #16983
### `@publicInBinary`
A binary API is a definition that is annotated with `@publicInBinary` or overrides a definition annotated with `@publicInBinary`. This annotation can be placed on `def`, `val`, `lazy val`, `var`, `object`, and `given` definitions. A binary API will be publicly available in the bytecode. It cannot be used on `private`/`private[this]` definitions.
#### Interaction with inline
This is useful in combination with inline definitions. If an inline definition refers to a private/protected definition marked as `@publicInBinary` it does not need to use an accessor. We still generate the accessors for binary compatibility but do not use them.
### `-WunstableInlineAccessors`
If the linting option `-WunstableInlineAccessors` is enabled, then a warning will be emitted if an inline accessor is generated. The warning will guide the user to the use of `@publicInBinary`.
1 Like
devlaam
February 6, 2026, 12:02pm
3
Thank you for looking into this @som-snytt . Where others would spend the non-upright position sleeping or getting well, or … , you are helping others so fantastic !!!
I played a little with this @publicInBinary annotation, but could not get it to work. So, or I am misunderstanding something, or some other force is at work here.
Anyway, imho this issue qualifies as compiler bug. If there are no objections, I will file one shortly (my second this week ). When looking through the list of open issue i found AbstractMethodError with abstract override and super accessors (since min 2018!!) which indeed still fails .
1 Like