Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

You're asking for a language change to fix poorly written code. The final else if() is redundant, if you change it to a simple else you remove the "not all code paths return a value" issue and remove a redundant check. This requires you to consider the "and others" possibility, rather than the compiler making assumptions about the type's definition.

Plus what you're asking for is a maintenance nightmare; since changing the type (Color) in one part of the code can break method definitions in another part of the code (inc. other assemblies).

I'd hope they would never support what you're asking for.

View on HN

He's asking for exhaustiveness checking of pattern matching algebraic data types. Many languages have had this for essentially forever.

It does sometimes mean that when you update some code, you have to update a bunch of other things. But it's rarely spurious. Usually those other things are broken by failing to consider the new possibility.

In the long term, it's a maintenance win.

But C# enums are a terribly weak data type, not a good implementation for the semantic you're looking for at all.

Better to ask for a C# union type and matching syntax.

If I add a "yellow" option to the enum, then I _want_ to get compiler errors (or warnings) about all the places in my code that need to handle that new case. That's what compilers are for, that kind of busy work.

Is there a way to write that SuperheroFromColor function so that I will get a compiler error (or warning) if another option is added to the enum? (Imagine that function is far away from the Color definition so it's not visually obvious.)

When I create an enum with three possible values, I reason about it as having only three possible values. As long as I never cast from an int, that should be true, right? So I don't want to consider the "and others" possibility. It's hard to even think about what to do in that situation, since it shouldn't happen.

I said that I'm willing to put some keyword before or after the if statement to tell the compiler to make sure I'm handling all valid enum values. So it can only give me these errors (or warnings) when I ask for them.

I think pattern matching in Haskell will make sure you handle all possible cases and give you a compiler error if you don't. I'm asking for a "poor-man's version of pattern matching for enums" in C#.

By turning the "else if" into an "if" you introduce a silent bug when Color.yellow is added, since the final else clause would now have to deal with both blue and yellow correctly.

Adding a new member to the Color enum should break code that isn't written to handle it: which is any code written before Color.yellow was introduced.

Created a compiler extension to help me:

https://github.com/abjennings/EnumAnalyzer

Reply on news.ycombinator.com