Operator overloading for collections?

[Red IO]

I think we are currently drifting away from "operators for
collections"/specific java standard classes to "custom operator overloading
for everyone" the later being a clear non goal everyone can agree on.

That an operator shouldn't be required to be looked into is clear.

On Tue, Sep 2, 2025, 14:50 Artyom Drozdov <artyomcool2 at gmail.com> wrote:

> > Numeric code is special.
>
> Yes, it is. That's why it feels bad to me to give users to much control on
> it. Comparing "how easy to write good code" with "how easy to prevent
> appearance of bad code", for me the second one is more important.
>
> > Not every feature added to Java should be used by every Java developer.
>
> Unfortunately, we can't prevent users from using "dangerous" features. The
> story of Unsafe proves that. We can't enforce rule "only certified
> developers can overload operators".
>
> > It would be added to the Java support easily.
>
> It is not about support. Navigate through methods easier from the UX
> perspective both with keyboard and mouse/touchpad, comparing with
> single-symbols operators. It's also goes against java users experience with
> operators, that just don't need to be examined.
>
>
> вт, 2 сент. 2025 г., 14:32 Aaryn Tonita <atonita at proton.me>:
>
>> > Most of the features that improve "writeability" reduce readability.
>>
>> Numeric code is special. The corresponding off by one error for a
>> numerical algorithm (or even deriving the equation) is messing up the sign
>> in a multi-line expression. Infix method chaining like
>> p.add(rho).multiply(r.pow(3).multiply(4 * PI) ... ) is not easier to read
>> for numerical code and precedence shoves whole terms inside methods in ugly
>> ways. Reviewing such code is very difficult because of the essential
>> complexity of the formula and the incidental complexity of the "FORmula
>> TRANslation" obscures it when the translation is so far. Reviewing such
>> code is more like a careful comparison with a spec than the logical review
>> that most developers perform.
>>
>> Not every feature added to Java should be used by every Java developer. I
>> really hope most developers never need to tweak garbage collector settings.
>> It would be great if the libraries underlying machine learning (lapack and
>> blas) could have competing pure Java implementations with reasonable user
>> api's for the subset of developers that need them and want to remain in
>> Java and interact with the Java ecosystem without polyglot pain.
>>
>> > It would be harder to use IDE to navigate.
>>
>> IDE's navigate to the implementation of the typeclass/method for operator
>> overloading in languages that support it. It would be added to the Java
>> support easily.
>>
>>
>> -------- Original Message --------
>> On 9/2/25 12:09, Artyom Drozdov wrote:
>>
>> 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/7a5d2721/attachment-0001.htm>