Operator overloading for collections?

Tue Sep 2 10:09:37 UTC 2025

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/789e309c/attachment-0001.htm>