Hyphenated keywords interacts badly with operator overloading

[Brian Goetz]

I think the bigger point here is that some keywords/reserved identifiers  (this, null, true, false, and soon switch) can be used in expressions, and that we should be more careful hyphenating those.  Which is a point that was left out of the first mail.  

> On Jan 23, 2019, at 11:25 AM, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 
> The problem isn't that the strawman syntax uses the symbol itself as name.
> 
> It's simply this: Right now if you write "x+this" in java, and if hypothetically speaking the H-K proposal worked with + instead of -, then that'd be an ambiguous construct: Is that 'the expression 'x' PLUS the expression 'this'', which would compile down to a string concat operation if x is of type 'String', or, is it the keyword 'x+this'?
> 
> With minus (dash), this problem doesn't come up, but that's only because neither 'null' nor 'this', which are the two keywords which can serve as a valid expression just by their lonesome, are ever legal in a binary op with the MINUS token: there is no way in current java to make 'x - null' compile. Nor can 'this - x' ever be legal. And therefore, 'x-null' is not particularly ambiguous; the 'it is a binary operation' interpretation always leads to to the conclusion that it'd be a compilation error.
> 
> But, introduce operator overloading, and all of a sudden 'this - x' or 'x - null' could actually be valid java. At which point, 'this-x' is ambiguous: Is it the keyword 'this-x', or the binary op: perform the operation 'MINUS' with parameters 'this' and 'x'.
> 
> There are solutions to this problem, and I don't think 'this might interact badly with any future attempts to add operator overloading' is a reason to rework the H-K proposal even if all imaginable solutions feel lackluster, but I'm a bit biased (I wouldn't want op overloading to be a part of the JLS), which is why I thought I'd mention it.
> 
>  --Reinier Zwitserloot
> 
> 
> On Wed, 23 Jan 2019 at 17:13, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
> 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 <mailto: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 <http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html>
> > 
> > --Reinier Zwitserloot
>