Default property initialization for interfaces

In Kotlin we can define properties on an interface, which is great because it means we can create default method implementations that make use of state. What I'd love to see is if we could also define default values for those properties.

I understand that it would have to work a little differently than methods. With methods the interface defines a static method and the auto-generated implementation calls that static method, passing in a receiver object.
Instead of having default properties affect the interface and creating a static property, I imagine the implementation would just use the default value unless multiple interfaces have the same property name, in which case it would need to be overriden (similar to methods, except no super<Foo>.someProperty)

The reason I’d like this is because it makes multiple-inheritance cleaner, where I can have a class implement several interfaces and not have to override all the properties for each one.

interface Foo {   protected var _bar: Int = 0 }

class FooImpl : Foo {
  override protected var _bar: Int = 0   // Redundant line, this would be compiled into FooImpl if there was no override.

Also, fixing protected methods and variables in interfaces would really help me a lot :). (KT-3029)


This is not planned for the nearest future

1 Like

This would be immensely helpful! It has been 5 years - could the team reconsider this?


It is a very brittle concept. What guarantee is there that the implementation will use a field to back the property in the first place. How would it interact with the various ways in which the value could be initialized? Basically there are many (non-obvious) ways in which the default value could be ignored.

Isn’t the OP simply asking for a way to make default interface methods? In that case, what is wrong with a default value to make it work for val?

1 Like

Yes, I would love this as well.

Not following what you mean. If an override for the var is not implemented in the class conforming to the interface, then it would just be the default value. If an override is implemented, then it uses the override value provided.

I understand the sentiment in favor of multiple inheritance, but semantically interfaces of an object are ultimately public methods and public properties generate them too.

One may also consider any kind of method as an interface, but I would rather see private/protected methods as helper functions or simply as part of the state of an object and a Java/Kotlin Interface (a collection of interfaces) shouldn’t make assumptions about the state of an object.

While this proposal offers a practical benefit, it assigns Java/Kotlin interfaces a new meaning which deviates from the original meaning of “interface”.

As much as I prefer multiple inheritance, I’m rather used to see this for classes instead for interfaces, but I think it is too late to argue about that.

Just to say it doesn’t strike me to introduce protected methods to interfaces and share them through interface inheritance.
I think it will be introduced anyway in Java some day.
Just the fact that they are tied to classes too irks me.