I think it's silly that we can't overload property...

# language-evolution

[Caleb B]

I think it's silly that we can't overload property setters. It's a fundamental Java feature and idiom, and it's so necessary that it's actually in the language already in a more brittle form: kotlin-assignment-plugin. The difference is that that plugin overloads the assignment operator itself to do completely unseen behavior, which is significantly less stable than just allowing setter overloading.

Heck, it even has precedent for delegating to other setters for the same property: using item = value instead of field = value.

I want your help to workshop a KEEP for this. Right now, my idea for it is:

var foo: () -> String
    get() = field
    set(value: () -> String) {
        field = value
    }
    set(value: String) {
        foo = { value }
    }

[Caleb B]

This would also serve as a complete replacement to the kotlin-assignment-plugin, with safer access and no unseen behavior.

There's also no callsite ambiguity that is any different from existing function callsite ambiguity, and it would have the exact same resolution: foo = myAny as String

[gildor]

There is a huge discussion about it in this 12 years old feature
https://youtrack.jetbrains.com/issue/KT-4075/Allow-setters-overloading-for-properties

[gildor]

I don't really think that KEEP is way to go, as practice shows, those KEEP will never be seriously concidered by themselves and better to share your findings, reasons and potential implemenbtation details to the issue and continue discussion there

[CLOVIS]

It's not planned at the moment. https://github.com/Kotlin/KEEP/discussions/430#discussioncomment-13435087

[gildor]

It's just not in short-term plans, so no existing KEEP, but looks it's in some backlog of features.
This why I suggest do not start KEEP, and instead continue adding use cases to the discussion

[CLOVIS]

Honestly, I don't really know if any other use-cases would change anything (other than bump the thread), it's fairly clear what this feature is for

[gildor]

yeah, maybe, but good practical (not theoretical samples) from actual code are more useful than just saying "Still not done? When" or opposite, try to write a KEEP which will not go anywhere
Examples help to write KEEP in future and adjust potential implementation details

[Caleb B]

The reason I want to make a KEEP, discussion, etc. specifically for this feature is because while there are many proposals that include this (union types, explicit backing fields, overloading the assignment operator, etc.), those always get pushback for very good reasons due to the other things they add.

As long as it keeps trying to get bundled with something else, it'll never happen. On the other hand, suggesting this feature on its own might actually get it pushed through, especially considering it's already used by Jetbrains internally in a worse way.

I'm also not sure if anyone actually listens to tickets, considering I've seen countless tickets like this without any Jetbrains interaction in the past decade. On the other hand, well-written KEEPs for even more complicated topics keep getting pushed through faster than these basic language features.

[CLOVIS]

I can't cite a single community-written KEEP that actually got traction, all the KEEPs are written by Kotlin team members

[Caleb B]

Oh wow. I probably should have seen that coming.

[gildor]

I want to make a KEEP, discussion, etc. specifically for this feature is because while there are many proposals that include this

KEEP discussion is already discussion of implemented/close to implement state, it can change as result of discussion, but create KEEP just to discuss is unnecessary, this for what issue tracker is

[gildor]

> I'm also not sure if anyone actually listens to tickets, considering I've seen countless tickets like this without any Jetbrains interaction in the past decade
Well, there are thousands of them. MNy experience actually shows if it about language feature, it got answers or just discussion from Kotlin team. And the team definitely reading tickets

And anyway, this feature discussed a lot by community and by kotlin team

[CLOVIS]

Since there is already a ticket, a new one would just be marked as duplicate. It's more productive to give a few new examples in the existing ticket to remind everyone it's still there