spec: clarify allowed implementation restrictions for switch statements

[josharian]

The spec (version January 5, 2016) says in the Expression switches section:

Implementation restriction: A compiler may disallow multiple case expressions evaluating to the same constant. For instance, the current compilers disallow duplicate integer, floating point, or string constants in case expressions.

Three questions about this:

• cmd/compile also disallows duplicate concrete type cases in type switches:

func f(e interface{}) {
    switch e.(type) {
    case int:
    case int:
    }
}

This generates the error duplicate case int in type switch. But this implementation restriction is not currently allowed by the spec. Should it be? Does it matter?

• cmd/compile also disallows unreachable type cases in type switches:

func f(e error) {
    switch e.(type) {
    case int:
    }
}

This generates the error impossible type switch case: e (type error) cannot have dynamic type int (missing Error method). But this implementation restriction is not currently allowed by the spec. Should it be? Does it matter?

• I would like to make cmd/compile disallow duplicate composite literal cases in expression switches, to enable binary search over them (cmd/compile: suboptimal compilation of struct-valued switch statements #15164). For example:

type A [1]int

func f(x A) {
    switch x {
    case A([1]int{1}):
    case A([1]int{1}):
    }
}

Currently, this fails to compile, but it is a bug (#15895). One could argue that such composite literals "evaluate to the same constant", but it's not a constant in the sense usually used in the spec.

[josharian]

I guess the last one would break backwards compatibility. I have another implementation approach for such dead cases (including duplicate nil cases in type switches). We might want to add a vet check for detectably duplicate cases, if the compiler isn't going to reject them, since they're almost certainly bugs. I'll file a separate issue for that.

[griesemer]

For type switches, the spec says (x is from x.(type)):

Cases then match actual types T against the dynamic type of the expression x. As with type assertions, x must be of interface type, and each non-interface type T listed in a case must implement the type of x.

That is, the spec already disallows using int as T if x is of type error per the example above (and int doesn't implement error).

Furthermore, given that the semantics of the type switch is essentially an if-else-if sequence, a duplicate entry is never reached. But all, gc, gccgo, and go/types complain about duplicate entries, so we should probably document that by disallowing them in the spec.

Finally, I've tried to disallow certain duplicate entries for expression switches before, several years back, and it met with some resistance. We most likely cannot change something here if the compiler allowed it until now otherwise we are violating the Go 1.0 guarantee.

[griesemer]

Since the compiler's don't permit duplicate types in type switches, we should probably disallow duplicate nils in type switches as well, per discussion with @randall77 and @ianlancetaylor . The nil case in type switches was added later, and it's arguably an oversight (bug) that compilers permitted them. go/types doesn't permit it.

[josharian]

Thanks, Robert. I filed #15906 for a possible vet check. So it sounds like the only outstanding todo here is to document that compilers may disallow duplicate entries in type switches.

[gopherbot]

CL https://golang.org/cl/23584 mentions this issue.