A proposal for supporting references to synthetic Java properties

[nikitabobko]

This feature has lots of problems. It needs extensive testing. Consider static isFoo, consider Kotlin -> Java inheritance, consider Java field + getter (who wins in resolution), consider references to other Java synthetic functions (Enum.values), consider K2

public class Jaba {
    public String publicField;

    public String getPublicField() {
        return publicField;
    }

    public static String getStaticFoo() {
        return "";
    }

    private String privateField;

    public String getPrivateField() {
        return "";
    }

    public String getALLAREUPPERCASE() {
        return "";
    }

    public String getGetFoo() {
        return "";
    }

    public String getFoo() {
        return "";
    }

    public String getClassClash() {
        return "";
    }

    class getClassClash {
    }

    public static boolean isStaticFoo() {
        return true;
    }
}

import kotlin.reflect.KProperty

fun main() {
    val a = Jaba::publicField // resolved to the field (but should be ambiguity)
    val b = Jaba::privateField // resolved to the method (expected)
    val g = Jaba::getClassClash // Overload resolution ambiguity (expected)

    Jaba().allareuppercase // does this weird Kotlin feature interfere with synthetic properties?

    // Probably unrelated because it's only about functions
    val c = Jaba::staticFoo // Unresolved reference
    val d = Jaba::isStaticFoo // works as KFunction

    val e = Jaba::getFoo // is getGetFoo() or getFoo() ?
    val f: KProperty<String> = Jaba::getFoo // is getGetFoo() or getFoo() ?
    // ^ e and f are different
}

I expect the KEEP document to prove that we cover all the cases

Corner cases are co-authored-by: Simon Ogorodnik, Pavel Mikhailovskii, Nikita Bobko

UPD: covered by Reference resolution strategy section