<div dir="auto">I know this is a strong topic for you and I saw many discussions about it especially with you defending the current state.<div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">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. </div><div dir="auto">Saying those are different from for example </div><div dir="auto">list += element</div><div dir="auto">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.</div><div dir="auto">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. </div><div dir="auto">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. </div><div dir="auto">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.</div><div dir="auto">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. </div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">In my opinion collection operators are equally if not more valid to exist than try with resource. </div><div dir="auto"><br></div><div dir="auto">In great regards </div><div dir="auto">RedIODev </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Sep 1, 2025, 22:04 Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;line-break:after-white-space">
<div>This is an understandable question, and one that occurs almost immediately when someone says “operator overloading.”   </div>
<div><br>
</div>
<div>And, there’s a very clear answer: this is a hard “no”.  Not now, not ever.  </div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>
<div style="color:rgb(0,0,0)">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="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">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="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">I realize this is not the answer you were hoping for.  </div>
<div style="color:rgb(0,0,0)"><br>
</div>
<div style="color:rgb(0,0,0)">
<div style="color:rgb(0,0,0)"><br>
</div>
</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Aug 21, 2025, at 7:01 PM, david Grajales <<a href="mailto:david.1993grajales@gmail.com" target="_blank" rel="noreferrer">david.1993grajales@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<p>Dear Amber team,</p>
<p>I hope this message finds you well.</p>
<p>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>This immediately made me think about potential use cases for collections—for example, using operators for union (<code>+</code>), difference (<code>-</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>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>I know this is still under discussion, I am just curious about this particular use case.</p>
<p>Thank you very much for your work and for your time.</p>
<p>Best regards, and always yours.</p>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div>