<div dir="ltr">It is my understanding that Gosling rejected operator overloading in Java because it had been misused in C++. It was often used improperly as a way to implement general purpose macros instead of consistent algebraic operations and thus made it difficult to reason about what an overloaded operator actually did in any context. But it's a very concise and convenient notation and its use in Python is one of the reasons why that language is so popular in data science. It allows code to flow more like mathematical operations. For example:<div><br></div><div>minusOneList: list[int] = [-1] * N   # creates a list of N elements all initialized to -1</div><div><br></div><div>Java will initialize an array with all elements set to 0, but for a different value you'd need to call Arrays.fill().</div><div><br></div><div>List, Set, and Map concatenation is also very easy to read and write with the overloaded + operator. Allowing * for collection operands could support dot product expressions. </div><div><br></div><div>Is this all just syntactic sugar? Maybe. But think about the code you'd have to write to get the dot product between two collections. It obscures the actual intent of the code.</div><div><br></div><div>Having spent the last couple of years writing Python code, I have found operator overloading to be a great tool to enhance the utility of custom classes. Maybe the fact that Java has never had them would make their adoption and use in the "correct" way easier. New tutorials could stress the design principles and their intended use cases, just like you did with the Optional class and annotations. Just because a feature has the potential for abuse doesn't necessarily override the benefits it could provide when correctly used. </div><div><br></div><div>- Rob</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Aug 21, 2025 at 4:06 PM david Grajales <<a href="mailto:david.1993grajales@gmail.com">david.1993grajales@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>
</blockquote></div>