Non-exhaustive Switch expressions - wrong warning (CS8509, should be CS8524)

Unity Engine
1

Hi,
I’m trying to escalate a specific warning to an error using csc.rsp.

This StackOverflow question helped me narrow down the warnings.
There are 2 related warnings:

  • CS8509 - “switch expression does not handle all possible values of its input type…”
  • CS8524 - “switch expression does not handle some values of its input type…”

The use case is a switch expression covering all members of an enum**,** but no default case.
Expected behaviour - CS8524, based on Rider build (.NET 5), also tested in [this web compiler](http://The use case is a switch expression covering all members of an enum, but no default case.)

7295290--882778--upload_2021-7-3_18-46-31.png
7295290--882778--upload_2021-7-3_18-46-31.png1302×554 39.3 KB

Actual behaviour - Unity raises CS8509.

Dotnet (csc.dll) will raise 8509 only if an enum member is actually misisng, as seen below)

7295290--882775--upload_2021-7-3_18-44-39.png
7295290--882775--upload_2021-7-3_18-44-39.png1148×575 38.7 KB

Tested in Unity 2020.3.71f1 with Mono with Android as a target, for both .NET 4.x and Standard 2.0.

P.S. - This may seem overly specific, but it’s necessary for a pattern I’m trying to implement, to force compile errors when new members added to an enum, but not handled in switches.
I think this can help avoid a lot of common bugs.

Thanks!

7295290--882772--upload_2021-7-3_18-41-16.png
7295290--882772--upload_2021-7-3_18-41-16.png1305×561 38 KB

2

I’m not super-keen on fiddling with compiler directives because they have a habit of going stale into the future, or working incorrectly when you upgrade compilers.

I would just put a default case in and handle it at runtime with a throw new System.NotImplementedException(); and move on.

1 Like
3

Well, according to some comments in this post over here that warning is a rather new addition to the compiler which was discussed over here. Recently I haven’t done any C# development at all. So I’m not really up-to-date where Unity currently stands in terms of compiler and platform version. Though that may also depend on your scripting backend, the used .NET version and your target platform. None of that was mentioned in your post.

4

I Understand what you’re saying, but since (afaik) Unity doesn’t change major compiler versions that often, I’d like to give it a shot. Throwing is the default solution (no pun intended), but the point is to try to get compile time safety instead of run time (and client) errors.

Added to post - Unity 2020.3.71f1 with Mono with Android as a target, tested on both .NET 4.x and Standard 2.0

From what I saw .Net 4.x should only support C# 7.x iirc, so given this is a C# 8 feature, I assume its some custom Unity /mono implementation? I’m not really sure how that works now since Unity supposedly uses roslyn but that doesn’t match what I’ve read about .Net/C# version matching