Operator overloading for collections?

[david Grajales]

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)
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>
> 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/b0834e28/attachment-0001.htm>