Operator overloading for collections?

[Brian Goetz]

To shed some additional light on this, the argument here is not _only_ philosophical.  There is also a complexity and semantic argument against.

Complexity.  Supporting operators for things like

    <collection> + <element>

Is probably an order of magnitude more complexity than the proposal I sketched at JVMLS, because this would also require the ability to declare _new signatures_ for operators.  The JLS currently defines the set of operators, their precedence, and their associativity, as well as their applicability.  We treat + as a (T, T) -> T function, where T is one of seven primitives that isn’t boolean.  Adding _more_ types to that set is a far simpler thing than also saying that the operator can have an arbitrary function signature, such as `<T, C extends Collection<? Super T>> (C, T) -> C` (as would be needed for this example.). Now, we need syntax and type system rules for how you would declare such operators, plus more complex rules for resolving conflicts.  And I suspect it wouldn’t be long before someone started saying “and we’ll need to control the precedence and associativity to make it make sense” too.  This is a MUCH bigger feature, and its already big.  For a goal that seems marginal, at best.

Semantics.  In the current model, we can tie the semantics of + to an algebraic structure like a semigroup, which can even express constraints across operators (such as the distributive rule.). This means that users can understand the semantics (at least in part) of expressions like `a+b` without regard for the type.  But, if we merely treated operators as “methods with funny names” and allowed them to be arbitrarily defined, including with asymmetric argument types, different return types, etc, then no one knows what + means without looking it up.  Seems a pretty bad trade — all the semantics for a little extra expressiveness.





On Sep 1, 2025, at 5:58 PM, david Grajales <david.1993grajales at gmail.com<mailto:david.1993grajales at gmail.com>> wrote:

Thanks for the answer Brian. It's an understandable position.

My best regards for all the java development team.


El lun, 1 sept 2025 a la(s) 3:04 p.m., Brian Goetz (brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>) escribió:
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<mailto: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/9720212a/attachment-0001.htm>