Operator overloading for collections?

[david Grajales]

Maybe doing nothing is an extreme position. Valhalla allows many numeric
types that almost any other language has (like Complex numbers and linear
equations ) and it would certainly be a shame if we must do.

var c3 = Complex.addition(c1, c2);

Instead of

var c3 = 1-i2 + 2-i3.

Or

var c3 = c1 + c2

I know good vs perfect situations are the most ungrateful tho.



El mar, 2 de sept de 2025, 5:09 a.m., Artyom Drozdov <artyomcool2 at gmail.com>
escribió:

> Hello Amber team,
>
> Current discussion, and especially Brian's point that "If this is how
> enough people feel [...] then we have to seriously consider doing nothing."
> makes me join the discussion to defend the "doing nothing" position.
> As a constant reader of amber's mailing list I feel that the position of
> conservative part of the Java community is presented mostly by the team,
> not by the end users. But we are also here. We are just very happy already
> by "not having" some features. And operator overloading is one of them.
>
> In contrast to position "it is ok to have more runtime errors", I would
> like to say that I'm very happy with Java's way to encourage easy-to-read,
> eyes-driven-debuggable code with low amount of context required to
> understand, what's going on here and what I can and can not do with that
> code without breaking it.
>
> Most of the features that improve "writeability" reduce readability. Some
> of them were even accepted and implemented by project Amber. And probably
> it is ok to have some trade-off here. But operator's overloading, as for
> me, looks like overkill. It would be much harder to guess what's going on
> in very realistic scenarios, like using + operator with result of method
> invocation (directly or with "var" keyword). It would be harder to use IDE
> to navigate. And easier to break by misunderstanding precedence or
> automatic conversion rules (if something of that would take place).
>
> So I just want to add some voice to the "do nothing" counter.
>
> Thank you,
> Artyom Drozdov
>
> вт, 2 сент. 2025 г. в 11:13, Aaryn Tonita <atonita at proton.me>:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> -------- Original Message --------
>> On 9/2/25 00:14, Brian Goetz wrote:
>>
>> To shed some additional light on this, the argument here is not _only_
>> philosophical.  There is also a complexity and semantic argument against.
>>
>> Complexity.  Supporting operators for things like
>>
>>     <collection> + <element>
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>
>>
>> On Sep 1, 2025, at 5:58 PM, david Grajales <david.1993grajales at gmail.com>
>> wrote:
>>
>> 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/20250902/367925e3/attachment-0001.htm>