Must switch/case statements all need to have the same integral type?

defer all non-critical X10 issues to 2.1.0.

Bulk defer all non-critical, non-blocker frontend issues to 2.1.0.

bulk defer of unresolved 2.1.0 bugs to 2.1.1.

bulk move of all unresolved issues from 2.1.1 to 2.1.2

defer all non-critical 2.1.2 issues to 2.2.

Need decision on whether or not this program should be legal.

It actually compiles with both backends.

Bumped to critical, because potential non-backwards compatible change.

This is a language design issue.

One potential viewpoint is that switch/case is semantically a cascaded series of == tests, in which case to be consistent with the semantics of == the types should be required to be the same.

Dave, by "same", do you mean that

var huge: Long; switch(huge) { case 10: break }

should fail, because 10 is not a Long? I'm not sure how lenient X10 chooses to be in allowing "value-safe" type coercions in comparisons.

Yes, that was what I meant. X10 is not at all lenient for == and != (x:int, y:long; x == y is a static error).

Dave, thanks. I cast my vote (no pun intended) for your "potential viewpoint": using "==" semantics. This is easy to understand for us all.

In the language spec, I'd be careful to include a small example of switch on a Long, just to avoid some frustration for your users, many of whom will be used to more lenient switches.

Agree with Dave and Jonathan – switch should use == semantics.

More fuel for the == fire: If we persistent in compiling 'switch' to 'switch' then every time we modify the representation of some type so that it is no-longer what c++ considers to be an int, e.g. if we make x10_int a struct (as has been discussed before), then we risk breaking the implementation of 'switch'.

Some water for the fire: We probably can't implement switch in terms of if (==) as well as the backend compilers can implement it in terms of jump tables and trees.

We should keep the requirement that the case labels are constant if-and-only-if we may ever want to do the jump table optimisations (or have someone else do them for us).

note, I was not proposing to implement switch by cascaded == in an if-then-else tree. I was drawing a parallel to == semantics and saying that implicit coercions at the X10 level should not be done to get the switch/case to have the same type. We're still going to implement as a switch/case in the target language.

Ah I mistook this bug report for being about the following problem:

val c = 'a';
switch (c) {
        case 'a': ...;
        default: ...;
}

Which causes a problem because x10_char is not an integer

SwitchTest.cc:16: error: switch quantity not an integer

at r21676 I updated SSCA1 for the 2.2 == changes (no implicit conversions). the "right" way to do this results in code that doesn't compile because we would like to switch on a Byte.

Here's an extracted piece of code that currently doesn't compile, but should.

class TestSwitch {
    static C1 = 1y;
    static C2 = 2y;

    static C3 = 1;
    static C4 = 2;

    public static def guess(i:byte) {
         switch (i) {
             case C1:
                 Console.OUT.println("1");
                 break;
             case C2:
                 break;
             case 3y:
                Console.OUT.println("3");
                 break;
         }
     }

    public static def guess2(i:int) {
         switch (i) {
             case C3:
                 Console.OUT.println("1");
                 break;
             case C4:
                 break;
             case 3:
                Console.OUT.println("3");
                 break;
         }
     }

     public static def main(args:Array[String](1)) {
         if (args.size == 0)
             return;
         val i = Int.parseInt(args(0));
         TestSwitch.guess(i as Byte);
         TestSwitch.guess2(i);
     }
}

Fixed in r21728.

bulk close of all 2.2.0 resolved issues.