Hyphenated keywords interacts badly with operator overloading

[Brian Goetz]

I think this argument assumes that the only way to overload operators is to implement a method whose name is “+”.  That is of course one way (and a pretty way) to do it, but not the only one — and almost surely not how we would approach it were we to go there.  

So I think the interaction here is mostly theoretical.  

> On Jan 23, 2019, at 10:48 AM, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 
> I am a strong advocate of NOT including operator overloading in languages,
> on the basis that so far, anytime a language adds it, even capable
> programmers just cannot resist and make crazy APIs with it.
> 
> Nevertheless, Brian's hyphenated keywords proposal[1] interacts a bit badly
> with operator overloading.
> 
> The specific trick with the hyphenated keyword (let's abbreviate that to
> H-K) is that the tokenizer and parser kinda wanna interpret 'unsigned-int'
> as 'subtract the expression 'int' from the expression 'unsigned', which is
> always gobbledygook which is what makes the H-K proposal tick.
> 
> But if H-K is part of the language and operator overloading is added later,
> you run into this uh-oh! situation (the implementation of how operator
> overloading works is entirely strawman and not to be taken seriously; I
> just needed some syntax to show off the problem is all):
> 
> given:
> 
> public class MyNumber implements OperatorOverloading {
>    /** This method would be invoked if you write (MyNumber)x - (MyNumber)y
> */
>    public MyNumber -(MyNumber other) { ... }
> 
>    public void problem() {
>        MyNumber instance = ...;
>        System.out.println( this-instance );
>    }
> }
> 
> Here the string 'this-instance' is intended as an H-K but it can be equally
> well interpreted as an op-overload based invocation: The idea of 'call the
> minus method, passing as params 'this' and 'instance', respectively).
> 
> I will shed absolutely no tears if we make the introduction of op
> overloading in java more difficult by adopting H-K. But, perhaps it is wise
> to at least make such a choice with open eyes: If H-K is adopted, this
> might come up later.
> 
> [1]
> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html
> 
> --Reinier Zwitserloot