Exhaustive switch seems likely to be backward incompatible if done well.
What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression. Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even though often the value of a match isn't used and might be the empty tuple it necessarily must *have a value.
It seems to me that today a Go Switch statement operating on days of the week can omit Thursday and compile just fine. Exhaustive switch means that's a compile error. If your "exhaustive switch" is optional or just emits a warning, it won't catch many of the problems for which exhaustive switch is the appropriate antidote.
This would only make sense on an enum type, which would be a completely new thing, so it can be introduced without breaking backward compatibility. Constants and switch on non-enum values would stay, because they are useful independent of enum types.
Yep, agreed. Maybe a new hypothetical `exhaustiveswitch` keyword could be added that would be backwards compatible, but it doesn't seem very Go-like to have such similar functionality as separate keywords.
Sum types overlap a lot with what interfaces over. So enhancing the language with proper sum-types would benefit from enhancing interfaces and switch statements.
However, zero values throw a wrench into this. The zero value of an interface is nil, so enhancing interfaces would require you to address what happens with an uninitialized variable. One of the current proposals suggests that nil continue as the zero value.
They could introduce a totally different type, like a sealed interface, which doesn't require a zero value, but that distinguishes between different types of interfaces, and I'm not sure how that'll be received.
What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression. Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even though often the value of a match isn't used and might be the empty tuple it necessarily must *have a value.
It seems to me that today a Go Switch statement operating on days of the week can omit Thursday and compile just fine. Exhaustive switch means that's a compile error. If your "exhaustive switch" is optional or just emits a warning, it won't catch many of the problems for which exhaustive switch is the appropriate antidote.