Re: Assignment Arithmetic operators

Per Nyfelt <[email protected]>
Newsgroups gmane.comp.lang.groovy.devel
Organization Alipsa HB
Message-ID <[email protected]>
I think this would be a great addition. I had this use case 2 years ago:

I have a class the is want plus to be immutable and plusEquals to be
mutable e.g:

def newMatrix = myMatrix + additionalRows

assert myObj == myMatrix - additionalRows

myMatrix += additionalRows

assert myMatrix == newMatrix

Since my implementation of plus involves cloning myMatrix which in my
case is expensive, it would be a big difference if I could avoid that
when there is no need. However += is calling plus and then assigning
the result under the covers. Is there a way to "get to it" to override?

Btw: PLUS_ASSIGN would be clearer than ADD_ASSIGN i think

Best regards,
Per

On 3/8/26 09:53, Paul King wrote:
> Hi Sterling,
>
> This is certainly something we could consider for Groovy 6. That is 
> currently where we'd like to put most of our focus, and where we have 
> some nice performance improvements that could be of benefit to Gradle 
> and other frameworks in the Groovy ecosystem. The current 
> implementation chose a very specific way to handle all of the 
> assignment operators, and this leads to simplicity and minimises edge 
> cases across the variations: ADD_ASSIGN, SUB_ASSIGN, MUL_ASSIGN, 
> DIV_ASSIGN, AND_ASSIGN, OR_ASSIGN, XOR_ASSIGN, MOD_ASSIGN, 
> LSHIFT_ASSIGN, RSHIFT_ASSIGN, URSHIFT_ASSIGN, and ELVIS_ASSIGN.
>
> The more backwards compatible the change is, the more likely it is we 
> could backport, but we'll be ramping down focus on Groovy 4 soon and 
> mostly attempting to handle critical bugs. Having said that, I am 
> interested in others' thoughts.
>
> Cheers, Paul.
>
>
> On Sun, Mar 8, 2026 at 6:33 PM Sterling Greene <sterling-J5J7/[email protected]> 
> wrote:
>
>     Hey Groovy people.
>
>     Groovy currently supports operators like a+=b by decomposing them
>     into a=a+b and + is implemented with a plus() method. Kotlin does
>     something similar.
>
>     Kotlin also supports overloading "augmented assignments":
>     https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments
>     which appears to just be another way of saying "assignment
>     arithmetic operators." In Kotlin, a type can implement plusAssign
>     and plus and the appropriate one will be selected depending on the
>     scenario.
>
>     My proposal is to add support in Groovy for these methods too.
>     Groovy would start calling plusAssign instead of decomposing into
>     an assignment and call to plus. There are details about fallbacks
>     and differences between static and dynamic Groovy, but I'm happy
>     to provide those if this seems like a reasonable idea.
>
>     I would also be willing to implement this.
>
>     My questions:
>
>     Is this reasonable and what's the best way to discuss this further?
>
>     Is it possible for this to be added to Groovy 4?
>
>     The reason Groovy 4 is important to us is that Gradle 9 currently
>     uses Groovy 4. We want to make API changes in Gradle 10 and the
>     current behavior of += with FileCollections is causing some
>     headaches. Getting support for overloading += directly in Gradle 9
>     could make the API changes in Gradle 10 less painful.
>
>     Thanks!
>
>     -- 
>
>
>     Sterling Greene
>
>     Senior Lead Software Engineer
>
>     Gradle Technologies
>     gradle.com
>     <https://gradle.com/>image.png
>
>
>     *
>     CONFIDENTIALITY NOTICE*: The contents of this email message, and
>     any attachments, are intended solely for the addressee(s) and may
>     contain confidential, proprietary and/or privileged information
>     legally protected from disclosure. If you are not the intended
>     recipient of this communication, or if you received this
>     communication by mistake, please notify the sender immediately and
>     delete this message and any attachments. If you are not the
>     intended recipient, you are hereby notified that any use,
>     retransmission, dissemination, copying or storage of this message
>     or its attachments is strictly prohibited.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.