I came up to think that something like explicit ab...

# language-proposals

[lhwdev]

I came up to think that something like explicit abstract would be really helpful for api authors, even though I do not really have a usecase.
When one add new abstract member to super class, if child class is not abstract, it would lead to errors. For example: there is

interface Super {
  fun a()
}

And

class Child : Super {
  override fun a() { TODO() }
}

If we add new member to Super, it will cause a compiler error to Child. What I want is, to have a same behavior(compiler error) even if Child is abstract class. So I need to explicitly implement all abstract members like:

interface Super {
  fun a()
  fun b() // new
}

@ExplicitAbstract
abstract class Child : Super {
  override fun a() { TODO() }

  // if this is absent, would lead to compilation error
  override abstract fun b() // if cannot implement here, mark as abstract
}

Note that I didn't think about how to mark it(here, @ExplicitAbstract) so don't care.
Honestly, this is just an idea and I don't know if it would be useful. What do you think?

[raulraja]

hi @lhwdev, Forcing the impl of all members non implemented from a super type is something we can accomplish already by flagging the Child as open. does this cover your use case?

interface Super {
  fun a()
  fun b() // new
}

open class Child : Super {
  override fun a() {
    println("Child.a")
  }

  override fun b() {
    println("Child.b")
  }
}

class GrandChild : Child()

If you can’t implement b in Child, why do you want to explicitly include the abstract empty declaration for it?

[raulraja]

What would happen when something like Child is also an interface and not a class?

[lhwdev]

This proposal is to explicitly state all abstract members in abstract class/interface. Adding new abstract member to api breaks compatibility, so if some api interface/abstract class extends other abstract one(Super) and Super adds new abstract member, this ensures explicitly break/keep source/binary compatibility.
I'm thinking that the same thing should apply when Child is interface.

[raulraja]

I see, makes sense for compat reasons then. Not sure if it will make it as a lang feature but if you end up motivated to build it for yourself this can be easily acomplished with a plugin that uses a declarationChecker and emits warnings or errors when inherited members are not declared in the type is annotated with @ExplicitAbstract