Hyphenated keywords interacts badly with operator overloading

Reinier Zwitserloot reinier at zwitserloot.com
Wed Jan 23 15:48:25 UTC 2019


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


More information about the amber-dev mailing list