Is there any chance `org.jetbrains.kotlin.plugin.a...

# language-evolution

[Daniel Pitts]

Is there any chance org.jetbrains.kotlin.plugin.assignment becomes integrated with the core language at some point? It's a nifty feature that I'd love to use in my own DSLs.

[Adam S]

Unlikely, because assignment overloading fails at runtime if it's used in delayed property assignment (more details at the end of this answer https://stackoverflow.com/a/76022933/4161471)

[Daniel Pitts]

Interesting. Seems like that issue could be resolved with a little language design though.

An alternative solution would be to allow setter overloads for properties. Something like;

var myProperty: CanonicalType 
    set(value: Int) {
       set(CanonicalType(value))
    }
    set(value: String) {
       set(CanonicalType(value.toInt())
    }

// or:
var other: Holder = Holder()
    set(value: Int) {
        field.hold(value)
    }

[Youssef Shoaib [MOD]]

Also, the compiler extension point for that can do slightly more complicated stuff. So theoretically this can be fixed. I've been working on a better assignment plugin that removes these limitations. I'll see if I can have a workaround for the initialisation thing

[Daniel Pitts]

TBH, I think the setter overloads would be a more useful feature over all. It's something that I've wished for in the past. Only reason I asked about assignment plugin was I noticed it used in gradle DSL.

[Adam S]

Adding assignment overload was proposed, but there was some push-back (the use-case was Gradle-focused, and it's potentially confusing), hence the compromise of a compiler plugin
https://github.com/Kotlin/KEEP/issues/309

[Youssef Shoaib [MOD]]

@Daniel Pitts I think the extension point is general enough that it can even support setter overloading. I'll look into that further...

[CLOVIS]

Personally, I would prefer setter overloading extended to also work with delegated properties, than have an assignment operator. The former seems more versatile and in line with the current Kotlin design

[Daniel Pitts]

yes, and the fact that you can approximate the same behavior (with different syntax) means it could be feasible to implement. I think the difficult part would be some of the edge cases, like generic setter with reifed types.