KEEP
KEEP copied to clipboard
Kotlin
A proposal for the assign operator overload
This is a proposal on providing an assign operator overload that would provide DSL for assigning values to mutable container objects.
Please, use KEEP-309 issue for discussion of this proposal and post text and editorial changes into this PR.
Im not a language designer of course, but IMO introducing this with coming 'explicit backing field' KEEP, with possible future introduction of 'setter overload' (which is also very useful for DSLs and with explicit backing field proposal it's even more logical and useful) and looking on design notes of value classes future improvements - all those proposals want to enhance user experience using assignment symbol. And so in codebase with all those things even in different places it will be SO HARD to understand what happens in some peace of code...
Even all those proposals are super useful and convenient, combination of them will remove one of the most beautiful feature of kotlin - code readability, and I feel not comfortable about it...
@whyoleg Note that this concern is addressed in the document as custom set functions are free to arbitrarily mutate your value today and do not need to write to a backing field.
Moreover, the backing field proposal is a syntactic optimization for a pattern that already exists.
So neither feature actually changes the semantics of how you read call sites. You have never known what assignment to a property will do behind the scenes and that has been true since Kotlin 1.0.
Also, in general, opinions on the proposal should go in the associated issue (#309) rather than on the PR where its comments should be reserved for improving only the language / content / syntax of the proposal.
Since we've rejected the idea of adding the corresponding convention, as described in the KEEP, to the language directly, but are providing an extension point that allows the similar implementation as a compiler plugin to be used in Gradle, I'm closing this PR and issue.
The documentation for the feature shall change (as only a specific Gradle DSL behavior needs to be documented) and shall be hosted elsewhere. The documentation of the extension points itself will be performed in the future during compiler API stabilization.
