<p dir="ltr">List is the free monoid over the type it collects so it would be quite semantically well formed, the underlying method is also called add. But lists are an interface in Java which really complicates things and constructing a new list each time + is used instead of guiding users to the add method feels like adding a footgun just for some free monoid nerdery. I have similar things to say about the mathematics of Set. As a library writer I would probably add it because I think it's cute, as a language architect / standard library writer it feels like you have the right of it. </p>
<p dir="ltr">I do hope you don't bind all operators together though, since the existence of an operator is what separates semigroups from groups and groups from rings and rings from fields... I need *, + and - over matrices, and then I need * on a matrix with a scalar or a vector, but no division in general. And left and right vector multiplication should differ. Then vectors have + and -, a scalar * but no vector multiplication because there's no canonical choice between tensor product and skew product and I didn't want to implement a tensor library at this point (I have seen ^ used for the skew product which matches the wedge symbol generally used but I wouldn't trust it on precedence and I definitely don't want to overload precedence so the semantics feel off). You can sort of implement division over matrices, but there are similar good reasons not to. Lifting math operators like sqrt and exp onto scalar fields will be fun though.</p>
<p dir="ltr">Anyway, even if I have to throw a couple UnsupportedOperationExceptions and get runtime errors instead of compiler errors, I will be quite happy. Looking forward to a preview of this. </p>
<div class="protonmail_quote">
<br>
<br>
-------- Original Message --------
<br>
On 9/2/25 00:14, Brian Goetz <brian.goetz@oracle.com>
wrote:
<br>
<blockquote class="protonmail_quote">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> To shed some additional light on this, the argument here is not _only_ philosophical. There is also a complexity and semantic argument against.
<div class="">
<br class="">
</div>
<div class="">
Complexity. Supporting operators for things like
</div>
<div class="">
<br class="">
</div>
<div class="">
<collection> + <element>
</div>
<div class="">
<br class="">
</div>
<div class="">
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.
</div>
<div class="">
<br class="">
</div>
<div class="">
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.
</div>
<div class="">
<br class="">
</div>
<div class="">
<br class="">
</div>
<div class="">
<br class="">
</div>
<div class="">
<br class="">
<div class="">
<div>
<br class="">
<blockquote type="cite" class="">
<div class="">
On Sep 1, 2025, at 5:58 PM, david Grajales <<a href="mailto:david.1993grajales@gmail.com" class="">david.1993grajales@gmail.com</a>> wrote:
</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
Thanks for the answer Brian. It's an understandable position.
<div class="">
<br class="">
</div>
<div class="">
My best regards for all the java development team.
</div>
<div class="">
<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">
El lun, 1 sept 2025 a la(s) 3:04 p.m., Brian Goetz (<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>) escribió:
<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div class="">
This is an understandable question, and one that occurs almost immediately when someone says “operator overloading.”
</div>
<div class="">
<br class="">
</div>
<div class="">
And, there’s a very clear answer: this is a hard “no”. Not now, not ever.
</div>
<div class="">
<br class="">
</div>
<div class="">
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.
</div>
<div class="">
<br class="">
</div>
<div class="">
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.)
</div>
<div class="">
<br class="">
</div>
<div class="">
<div style="" class="">
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.
</div>
</div>
<div style="" class="">
<br class="">
</div>
<div style="" class="">
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.
</div>
<div style="" class="">
<br class="">
</div>
<div style="" class="">
I realize this is not the answer you were hoping for.
</div>
<div style="" class="">
<br class="">
</div>
<div style="" class="">
<div style="" class="">
<br class="">
</div>
</div>
<div class="">
<br class="">
</div>
<div class="">
<div class="">
<br class="">
<blockquote type="cite" class="">
<div class="">
On Aug 21, 2025, at 7:01 PM, david Grajales <<a href="mailto:david.1993grajales@gmail.com" target="_blank" class="">david.1993grajales@gmail.com</a>> wrote:
</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<p class="">Dear Amber team,</p>
<p class="">I hope this message finds you well.</p>
<p class="">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.</p>
<p class="">This immediately made me think about potential use cases for collections—for example, using operators for union (<code class="">+</code>), difference (<code class="">-</code>), 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.</p>
<p class="">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?</p>
<p class="">I know this is still under discussion, I am just curious about this particular use case.</p>
<p class="">Thank you very much for your work and for your time.</p>
<p class="">Best regards, and always yours.</p>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</brian.goetz@oracle.com>
</div>