4 ms·

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 t

by seren 7y ago

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)

ZephyrP 7y ago
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`
- seren 7y ago
  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.
  - SAI_Peregrinus 7y ago
    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.
    - marcosdumay 7y ago
      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.
- nicoburns 7y ago
  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.
AsusFan 7y ago
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.
- ZephyrP 7y ago
  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"
  - threatofrain 7y ago
    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?
    - nicoburns 7y ago
      TS actually has quite an advanced type system compared to languages like Java.
  - hopia 7y ago
    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
  - a1369209993 7y ago
    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.
jcelerier 7y ago
> 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).
hellofunk 7y ago
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.
- LessDmesg 7y ago
  Enums are no substitution for sum types, though.
  - hellofunk 7y ago
    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.
The_rationalist 7y ago
Kotlin also enforce exhaustivity in when(), for enums and ADTs (sealed class's)

by seren 7y ago

ZephyrP 7y ago

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`

seren 7y ago
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.
- SAI_Peregrinus 7y ago
  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.
  - marcosdumay 7y ago
    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.
nicoburns 7y ago
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.

AsusFan 7y ago

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.

ZephyrP 7y ago
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"
- threatofrain 7y ago
  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?
  - nicoburns 7y ago
    TS actually has quite an advanced type system compared to languages like Java.
- hopia 7y ago
  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
- a1369209993 7y ago
  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.

jcelerier 7y ago

> 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).

hellofunk 7y ago

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.

LessDmesg 7y ago
Enums are no substitution for sum types, though.
- hellofunk 7y ago
  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.

The_rationalist 7y ago

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