<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Sep 1, 2025 at 5:13 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
To shed some additional light on this, the argument here is not _only_ philosophical.  There is also a complexity and semantic argument against.</div></blockquote><div><br></div><div> Personally I'm happy with the way things are but this is also an interesting discussion.</div><div><br></div><div>The "complexity" and "semantic" counter-arguments are compelling but I'm still missing something. It seems like those counter-arguments would be (mostly) addressed by making the new operator feature merely "syntactic sugar", like for-each loops and try-with-resources.</div><div><br></div><div>To give a concrete example, consider this proposal (this is just for discussion! I am seeking understanding/clarification, not agreement)...</div></div><div class="gmail_quote"><br><div>Consider an expression like <span style="font-family:monospace">a <a class="gmail_plusreply" id="m_-3365410692543025408plusReplyChip-0">+</a> b</span>. Let A be the compile-time type of A, and suppose A is not a primitive class.</div><div><br></div><div>Then <span style="font-family:monospace">a + b</span> would compile if and only if t<span style="font-family:arial,sans-serif">he e</span>xpression  <span style="font-family:monospace">a.operatorPlus(b) </span><span style="font-family:arial,sans-serif">would compile - and it would have</span><span style="font-family:arial,sans-serif"> the exact same meaning.</span></div><div><br></div><div>Similarly,  <span style="font-family:monospace">a + b * c</span> <<  d  would just be syntactic sugar for  <span style="font-family:monospace">a.operatorPlus(b.operatorTimes(c)).operatorLeftShift(d)</span><span style="font-family:arial,sans-serif">, etc. The rules for precedence and evaluation order stay the same.</span></div><div><div><br></div><div>In other words, we declare that  <span style="font-family:monospace">a + b</span>  and  <span style="font-family:monospace">a.operatorPlus(b)</span>  are just two different spellings of the same abstract 
concept (if it exists, whatever it is)... so no need to differentiate between them. It's just a new syntax for the same thing - if such a thing is defined.</div><br></div><div>Re: Complexity:</div><div>- Operator associativity and precedence does not change.</div><div>- "Ability to declare new signatures" - use method overloading to declare multiple <span style="font-family:monospace">operatorPlus()</span> variants taking different argument types</div><div>- "Applicability" and "resolving conflicts" - handled using the normal method selection process.</div><div>- "...it wouldn’t be long before someone started saying 'and we’ll need to 
control the precedence and associativity to make it make sense'"  - Hard no!</div><div><br></div><div>Re: Semantics:</div><div>- "no one knows what + means without looking it up" - isn't that already the case today?</div><div>  - To understand <span style="font-family:monospace">a.foo(b)</span> you must understand method <span style="font-family:monospace">A.foo(b)</span></div><div>  - To understand <span style="font-family:monospace">a + b</span> you must understand method <span style="font-family:monospace">A.operatorPlus(b)</span></div><br><div>The new methods allow arbitrary user code to participate, so they "grow the language" in an open way.</div><div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm not saying there aren't still OTHER reasons not to add such a feature, I'm just trying to narrow down what they are.</div><div><br></div><div>(Also, the question of whether, given this new feature, we would retrofit existing collection classes is a completely separate 
(and possibly more contentious) discussion.)</div></div><div><br></div><div>Thanks,<div>-Archie</div></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</div>