Any thoughts on having an annotation that could be...

# language-evolution

[eygraber]

Any thoughts on having an annotation that could be applied to abstract functions or properties that would force an immediate child to implement it? The use case is that I have a hierarchy of abstract classes and don't control the final concrete class, but I want to ensure that one of the abstract classes in the hierarchy will implement the abstract function or property.

[CLOVIS]

Why do you want to do this?

[eygraber]

I'm building a framework that uses https://github.com/evant/kotlin-inject and I provide an abstract class that the user will extend from another abstract class (kotlin-inject will generate the concrete class with KSP). The intermediate abstract class needs to implement an abstract property, because KSP isn't able to generate it.

[CLOVIS]

In my opinion, if this is a problem caused by code generation, then it's out of scope for a language evolution. Code generation is side-stepping what the language allows, so the language shouldn't adapt to use cases that stem from that. Instead, I would create a feature request to KSP or elsewhere.

(of course, I'm not the one who makes the rules, but I think it's unlikely this leads to anything)

[eygraber]

This isn't caused by code generation; my specific use case involves code generation, but the underlying issue is still there.

Another example would be a library providing an abstract class meant to be extended by an abstract class from another library. There's the same lack of control of implementation.

[CLOVIS]

Yes, but I believe it's on purpose. Abstract classes define classes "with holes" that implementations need to fill in. An abstract class cannot force an implementation to be of a specific kind; you can always implement them as object , class , anonymous objects, etc. The implementation has entire control over this.

Your use case is an abstract class that wants to force its implementation to 1) be an abstract class, and 2; implement a subset of its methods. I do not think this aligns with the language's goals, however it could maybe be a #detekt rule or something similar? Or just a different design that doesn't require something like this at all.

[eygraber]

It wouldn't force the implementation to be an abstract class, just that if it is an abstract class, it has to implement the annotated properties/functions.

It also doesn't force what the implementation is, but that the direct child provides an implementation. This isn't such a large leap, because currently:

1. If the child of an abstract class is a concrete class, it must provide an implementation
2. If the child of an abstract class is an abstract class, it may provide an implementation
I'm just asking for a way to bridge that. I don't think there's a way for static analysis to address this, since it would suppose that a consumer (which is not under your control) would be using static analysis.