Referring to value constructors with uppercase name results in runtime errors

I’ve discovered that if a value constructor is referred to in uppercase syntax, the JS backend emits ClassName$c_ConstName instead of ClassName$c_ConstName() (missing parentheses). This means that the value you get at runtime is a function instead of a proper object. When switching on the object, cases written in lowercase syntax will not match.

shared class C of \iA {
    shared String x = "x";
    shared new \iA {}
}

shared void run() {
    // without \i, no ()s are emitted
    C c1 = C.A;
    switch (c1)
    case (C.A) { print("A1"); } // works, but ===s the function instead of the actual value
    switch (c1)
    case (C.\iA) { print("A2"); } // doesn’t work
    print(c1.x); // prints "<null>"

    // with \i, ()s are emitted
    C c2 = C.\iA;
    switch (c2)
    case (C.A) { print("A3"); } // doesn’t work
    switch (c2)
    case (C.\iA) { print("A4"); } // works properly
    print(c2.x); // prints "x"
}

(You can get the same effect with a lowercase constructor name and \I references.)

I’m not sure why it’s legal to refer to the value constructor by UIdentifier (edit: perhaps #6099, as in #6287?), but as initial uppercase names seem to be the convention for TypeScript enums (which correspond to classes with value constructors), it would be preferrable to keep this legal.

[lucaswerkmeister]

“redeclare this bug as a feature”, if you prefer 😉

[gavinking]

I could rewrite them to lowercase, but that would only work if there’s no collision, and users might be confused why the names changed.

This is exactly what you should do. We already do this kind of thing in the Java backend for lots of things.