Operator overloading for collections?

[Red IO]

I know this is a strong topic for you and I saw many discussions about it
especially with you defending the current state.
I'm not writing this to try to change your mind. I know your take on this
is clear. But for the sake of the open discussion I'm writing this in
defense of the great (not new) proposal.

But enough with the foreword. I think the numbers are special argument is
pretty weak and falls apart as soon as you look at it. Saying numbers and
their operators belong to math and are easy to grasp because of familiarity
while saying we shouldn't have operators for list, sets and (and Tuples) is
denying that both are equally part of basic math as numerals themselves.
You can even define numbers by an arrangement of sets.
The problem is that mathematical operations for container structures are
operators like unions and intersections. Operators that aren't found as a
key on our keyboards. We won't change what's on keyboards that's clear.
The approach also used in Java and other languages for numerical operations
not usually done in math like += or ++ which deviate from the math
background of operators is to combine characters to form new operators.
Something that has become a common building block for many syntax
constructs of modern languages.
This approach which is also used in Java directly contradicts the math
origin argument for operators. We already have non math operators in Java
not even mentioning the infamous string concat operator or the exception
union operator.
Saying those are different from for example
list += element
Is purely denial. Sure you can say those where mistakes but I don't see
anyone arguing to not use these "mistakes" every day and instead do the
proper conversation and concatination with methods.
Also the argument that new operators would create situations where it's
unclear what it does completely falls apart on the string concat operator
which is an arguably worse offender in this regard then many potential
operators for container types. You have a magic toString call on types that
could have potentially multiple string representations while being messy in
conjunction with order of operations with addition.
Another common argument why the string concat operator is different is that
it was needed because string concatination is so common and it would be too
messy and less readable to write it all in methods.
Guess what thats the same thing for container types. Having operators for
basic operations on containers would improve code readability drastically.
In some cases we can clearly reuse existing operators without any chance of
confusion. In other cases new operators could be assembled from symbols.
Especially operators for collection creation would significantly help
improve readability instead of making things harder to read like you
suggested.
It's not the goal to come up with an operator for each and every basic
method of Java classes nor is it the goal to allow custom overloads of user
types. Both have many good arguments against them.
But it's really time to lift some basic operations that are currently
buried in oop syntax hell (like new ArrayList<String>() vs. []) to proper
language features with their own operators.
Try with resources is an example where it was done and it was a success.
It's undeniably just an operator for a close() call in the finalizer while
not being a familiar syntax.
In my opinion collection operators are equally if not more valid to exist
than try with resource.

In great regards
RedIODev

On Mon, Sep 1, 2025, 22:04 Brian Goetz <brian.goetz at oracle.com> wrote:

> This is an understandable question, and one that occurs almost immediately
> when someone says “operator overloading.”
>
> And, there’s a very clear answer: this is a hard “no”.  Not now, not ever.
>
>
> Operators like `+` are not just “methods with funny names and more complex
> priority and associativity rules”  The reason that Java even has operators
> like + in the first place is that _numbers are special_, and that we want
> code that implements mathematical calculations to look somewhat like the
> math it is calculating.  Numbers are so special, and so important, that a
> significant portion of foundational language design choices, such as “what
> kinds of built-in types do we have”, “what built-in operators do we
> support”, and “what conversions between built-in types do we support” — are
> all driven by numerical use cases. In earlier programming languages, such
> as Fortran, the language design process largely stopped here — most of the
> language specification was about numbers and numeric operators.
>
> Similarly, the only reason we are _even considering_ operator overloading
> now is for the same reason — to support _numerical_ calculations on the new
> numeric types enabled by Valhalla.  (And even this is a potentially
> dangerous tradeoff.)
>
> It is a core Java value that “reading code is more important than writing
> code”; all of this complexity was taken on so that reading _numerical_ code
> could look like the math we already understand.  One does’t have to consult
> the Javadoc to know what `a+b` means when a and b are ints.  We know this
> instinctively, because we have been looking at integer arithmetic using
> infix operators since we were children.  But once you leave this very
> narrow realm, this often becomes something that benefits writing code more
> than reading code.  And for every “but this seems perfectly reasonable”
> example, there are many more “please, kill me now” examples.
>
> For sure, the restrictions we set will be constraining, and they will
> eliminate some things that seem entirely reasonable.  And surely bad
> programmers will move heaven and earth to “outwit” the “stupid” compiler
> (as they always have.)  But the reason we are even doing this is: numbers
> are special.
>
> I realize this is not the answer you were hoping for.
>
>
>
>
> On Aug 21, 2025, at 7:01 PM, david Grajales <david.1993grajales at gmail.com>
> wrote:
>
> Dear Amber team,
>
> I hope this message finds you well.
>
> I recently watched Brian’s talk "Growing the java language" and I
> found the discussion on operator overloading particularly interesting. I
> appreciated how the proposed approach allows operator overloading in a more
> restricted and safer way, by enforcing algebraic laws.
>
> This immediately made me think about potential use cases for
> collections—for example, using operators for union (+), difference (-),
> exclusion, and similar operations. However, since this feature is intended
> to be limited to value classes, and the current collection classes are not
> value-based, it seems they would not benefit from these new operator
> overloading capabilities.
>
> My question is: are there any plans to enhance the collections framework
> with value-class-based variants, so that they could take advantage of this
> feature? Or is this idea (or any other related to the use case) not
> currently under consideration?
>
> I know this is still under discussion, I am just curious about this
> particular use case.
>
> Thank you very much for your work and for your time.
>
> Best regards, and always yours.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250901/5b2a5243/attachment-0001.htm>