<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">That an operator shouldn't be required to be looked into is clear. </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Sep 2, 2025, 14:50 Artyom Drozdov <<a href="mailto:artyomcool2@gmail.com">artyomcool2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>> Numeric code is special.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> Not every feature added to Java should be used by every Java developer.</div><div dir="auto"><br></div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto">> It would be added to the Java support easily.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">вт, 2 сент. 2025 г., 14:32 Aaryn Tonita <<a href="mailto:atonita@proton.me" target="_blank" rel="noreferrer">atonita@proton.me</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">> Most of the features that improve "writeability" reduce readability.</p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">> It would be harder to use IDE to navigate.</p>
<p dir="ltr">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.</p>
<div>
<br>
<br>
-------- Original Message --------
<br>
On 9/2/25 12:09, Artyom Drozdov <u></u>
wrote:
<br>
<blockquote>
<div dir="ltr">
Hello Amber team,
<div>
<br>
</div>
<div>
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.
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
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).
</div>
<div>
<br>
</div>
<div>
So I just want to add some voice to the "do nothing" counter.
</div>
<div>
<br>
</div>
<div>
Thank you,
</div>
<div>
Artyom Drozdov
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">
вт, 2 сент. 2025 г. в 11:13, Aaryn Tonita <<a href="mailto:atonita@proton.me" rel="noreferrer noreferrer" target="_blank">atonita@proton.me</a>>:
<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div>
<br>
<br>
-------- Original Message --------
<br>
On 9/2/25 00:14, Brian Goetz <u></u> wrote:
<br>
<blockquote>
To shed some additional light on this, the argument here is not _only_ philosophical. There is also a complexity and semantic argument against.
<div>
<br>
</div>
<div>
Complexity. Supporting operators for things like
</div>
<div>
<br>
</div>
<div>
<collection> + <element>
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
<div>
<div>
<br>
<blockquote type="cite">
<div>
On Sep 1, 2025, at 5:58 PM, david Grajales <<a href="mailto:david.1993grajales@gmail.com" rel="noreferrer noreferrer" target="_blank">david.1993grajales@gmail.com</a>> wrote:
</div>
<br>
<div>
<div dir="ltr">
Thanks for the answer Brian. It's an understandable position.
<div>
<br>
</div>
<div>
My best regards for all the java development team.
</div>
<div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">
El lun, 1 sept 2025 a la(s) 3:04 p.m., Brian Goetz (<a href="mailto:brian.goetz@oracle.com" rel="noreferrer noreferrer" target="_blank">brian.goetz@oracle.com</a>) escribió:
<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>
<div>
This is an understandable question, and one that occurs almost immediately when someone says “operator overloading.”
</div>
<div>
<br>
</div>
<div>
And, there’s a very clear answer: this is a hard “no”. Not now, not ever.
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
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.)
</div>
<div>
<br>
</div>
<div>
<div>
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.
</div>
</div>
<div>
<br>
</div>
<div>
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.
</div>
<div>
<br>
</div>
<div>
I realize this is not the answer you were hoping for.
</div>
<div>
<br>
</div>
<div>
<div>
<br>
</div>
</div>
<div>
<br>
</div>
<div>
<div>
<br>
<blockquote type="cite">
<div>
On Aug 21, 2025, at 7:01 PM, david Grajales <<a href="mailto:david.1993grajales@gmail.com" rel="noreferrer noreferrer" target="_blank">david.1993grajales@gmail.com</a>> wrote:
</div>
<br>
<div>
<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>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote><u></u>
</div>
</blockquote>
</div>
</blockquote>
<u></u>
</div></blockquote></div></div></div>
</blockquote></div>