You could be able to access this, but all the fiel...

# language-proposals

[louiscad]

You could be able to access this, but all the fields not defined as constructor parameters would be non accessible (marked as not initialized yet), unless it's from a lambda (like the one in lazy { … })

[Dico]

If you change the behaviour to evaluate on each access instead of on construction, the expression is not necessarily evaluated on construction anymore. It's like having a val with a getter that uses field-backed properties you declared later. That's allowed in Kotlin, thankfully.

[louiscad]

I don't think it's right to evaluate the expression each time, because it would be inconsistent with how it works for property delegation.

[louiscad]

Unless this is with a real delegate (with getValue) as mentioned in the channel

[Dico]

Interface delegation and property delegation are very different things. Evaluating the expression each time gives the most power to the developer.

[Dico]

Having to wrap an interface and implement all its functions defeats the purpose, so you wouldn't use interface delegation feature in that case. With property delegation, the idea is that you implement the getter and the setter in the delegate, so you don't have to write getter and setter boilerplate (if you repeat the same code over and over). That doesn't make sense with interfaces.

[Dico]

Speaking of property delegates, I hope they look at opportunities with inline classes soon to avoid storing the delegate in a field under the hood.

[louiscad]

I see, the problem is not so easy to tackle. Thanks for your insight!

[Dico]

Thanks for listening. It's difficult indeed, made worse by the similar names of the two features. I hope they look at it at some point but since it's not a critical feature, I can see why other things are going first.

[louiscad]

Yeah, that's why your last message (before this one I'm replying to) made me realize again: these two features use the same keyword and the same "delegation" name, but they're very different in fact! That doesn't mean this needs to change, but maybe the by keyword is not the optimal keyword for interface implementation by delegation, or maybe it should not be the only keyword (you can think of a companion keyword) used for more advanced use cases.

Going further more advanced use cases support should have two things:
1. Declaring an interface is implemented by delegation, without providing the delegating property in the class declaration
2. Linking a property to be the delegated interface implementation (and your property can be a getter under the hood that is re-evaluated each time if you want)

[louiscad]

Then, the compiler could go as far as flagging as error any access on the interface functions & properties before delegating property linking. Delegating property linking inking would follow the order, like the constructors, fields initialization and init blocks.

[Dico]

Yeah, I absolutely agree with you. The proposal from the KEEP that I like the most is delegate val (or var)

[Dico]

it does exactly what you say - it moves declaration of the delegate into the class body, where it belongs, because it is an implementation detail, and it moves away from the by keyword.

[Dico]

And then you can use a getter if you want something to be evaluated each time.

[Dico]

And then you can write delegate val a: Interface by b

[Dico]

and then people get confused, but yeah