Operator overloading for collections?

[Ethan McCue]

> 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.

I'll say what I think we're all a little too scared to say - this is all
the math dorks' fault. Stupid single character operators made to be written
on big old blackboards with artistinal Japanese chalk. What's that? Two
different kinds of multiplications for vectors? You can tell them apart
because one is a dot and one is a cross? Well guess what, we invented the
most cross-looking dot out there and it's whats for dinner: *

> just like you did with the Optional class

I think that is an example of something where no amount of stressing design
principles seems to make a dent in how many fights there are about it.


On Fri, Aug 22, 2025 at 5:04 PM Rob Ross <rob.ross at gmail.com> wrote:

> 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:
>
> minusOneList: list[int] = [-1] * N   # creates a list of N elements all
> initialized to -1
>
> Java will initialize an array with all elements set to 0, but for a
> different value you'd need to call Arrays.fill().
>
> 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.
>
> 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.
>
> 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.
>
> - Rob
>
>
>
> On Thu, Aug 21, 2025 at 4:06 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/20250822/bef9b62f/attachment-0001.htm>