Hacker News Reader

Comment by seren | Hacker News Reader

If you have a Rust enum with Color{Red,Green,Blue), if for some reason you update to Color{Red,Green,Blue,Yellow}, the rustc compiler will force you to manage the new Yellow case wherever you want to "match" a pattern on Color, so overall you have less chance to forget to manage the new case everywhere. This kind of error is not managed by a C or C++ compiler (as far as I know).

But from my understanding, this is not directly related to the borrow checker, which tracks who owns a reference and is allowed to modify it or not.

(That being said if you had a "default" case earlier, the compiler won't complain)

View on HN

If you compile with `-Wall` GCC will emit a warning for failing to exhaustively check enum values inside a switch statement

(I don't remember the specific underlying feature flag name, sorry).

EDIT: It's called `-Wswitch`

Yes, apparently, there is a -Wswitch statement in gcc, which looks quite similar, maybe I have used too old compilers...

> Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration. (The presence of a default label prevents this warning.) case labels outside the enumeration range also provoke warnings when this option is used (even if there is a default label). This warning is enabled by -Wall.

The issue with -Wswitch (and thus -Wall) is that the presence of a default case suppresses the warning. Which you may not want, if you need non-default behavior because you're adding a new value! There's -Wswitch-enum (not turned on by -Wall or -Wextra) that stops this being suppressed. This is good, though the (possible) list of cases that are well-handled by the default at the end of switches that just fall-through can be ugly.

A default case supreses the warning in Haskell too, there is no other option.

The real problems with C enums aren't about matching completion, they are that:

- There is no guarantee that a variable value is in the enum range;

- A C (or Java, or C#) enum is a very poor type and can not represent all the data that a Rust enum carries. Developers usually use them with union types to solve that problem, but then there aren't any warnings for most problems anymore.

The big difference is that C++ emums can't contain data. C++ has checking on enums, but enums are a relatively niche data structure for specific use cases.

In Rust, enums are a core data structure with completely equal status to structs, and are used pervasively throughout the language including the standard library.

Notably, both Option (which is used instead of null) and Result (which is used for error handling) are enums, which means that you thse correctness checks for every null and every error condition, on by default. Thats a huge deal as these are often the source of unexpected runtime errors.

> This kind of error is not managed by a C or C++ compiler (as far as I know).

C++ had boost.variant which did exhaustiveness checking since ... 2002 (and an std version since C++17).

Many people have their compilers set to enforce these things, and many of us go a step further and make our compiler warnings into errors so it’s impossible to build a program with these errors. That’s very commonplace, and C++ does it just fine. Missing cases in enums and at least 100 other very common matters can be checked at compile time in C++, the only difference is that it’s not the default as it is in some other languages.

Enums are no substitution for sum types, though.

The comment I was responding to was not about the functionality of a sum type, but rather the compilation errors from leaving out a case. Those are two different matters.

Kotlin also enforce exhaustivity in when(), for enums and ADTs (sealed class's)

This isn't particular of Rust. Nim also forces you to deal with all possible branches of a case statement. I'm pretty sure other languages do so as well.

This is just basic type safety stuff.

plenty of other languages do so, but it's both unfairly diminishing to the parent & questionably correct to refer to it as "basic type safety stuff"

JS has this too in TS, so I’m pretty sure the perception among users of typed languages is that this is a basic part of what type systems do. What does this have to do with FP?

TS actually has quite an advanced type system compared to languages like Java.

On the other hand, it's not a very advanced type level feature either to insist on total functions. I'm sure Rust's type system goes a lot further in enforcing a good level of type soundness.

Edit: typo

No, it is basic. If you have a sum type, and you have no defined behaviour for one of the terms of the sum type, your code is not type-safe and a language that aspires to "basic type safety stuff" should at least issue some kind of error about it. In a putatively statically-typed language (ie one that does type checking at compile time), you'd expect that error to happen at compile time.

Reply on news.ycombinator.com