3 ms·

I would probably manually update the enum and the corresponding match statement. If possible, I'd write a test to check that the two don't get out of sync. I'm

I would probably manually update the enum and the corresponding match statement. If possible, I'd write a test to check that the two don't get out of sync. I'm not too familiar with Rust so I'm not sure if the test code would be simpler than the macro solutions or the hack, but I think it would be.

mplanchard 5y ago
Iterating over an enum requires a macro (strum::EnumIter is a popular one), which you’d need in order to ensure the test code automatically covers all cases without needing updates. This does only work when your variants are non-data variants or data variants whose type implements Default, but it does allow you to force yourself to stay in sync. Edit: you might could also do some shenanigans using integers, `as` conversions, and #[repr(u8)], but it seems like it would get nasty and potentially unsafe
- Groxx 5y ago
  An iterator macro seems fine? You could apply it only during the tests, for example, so it's not like it needs to be exposed in your library.
- nmilo 5y ago
  An unsafe block is significantly better than the code proposed in the article.
  - justin_oaks 5y ago
    I know some people get upset when unsafe is used when there's a "safe" alternative, but unsafe isn't too bad in test code, is it? The concerns of undefined behavior, data races, use-after-free, etc. seem a lot less consequential in test code.
    - nmilo 5y ago
      Unsafe isn't too bad in any code. The point of unsafe is that it is a declaration that the programmer has verified the code is safe. It is certainly easier to verify something along the lines of: unsafe { transmute::<u32, Error>(error_code) } than it is to verify that the weird macro code in the article is correct. There is no data races, use-after-free, etc. in that block, it does exactly what the article needs. To me, Rust programmers seem to have a weird notion that just the word "unsafe" is enough to conjure demons and monsters into otherwise totally normal code.
      - Nullabillity 5y ago
        You'd think so, but that code is far into nasal demon territory. Both because the default byte representation of an enum isn't stable, and because an out-of-bounds enum value (wherever it comes from) is always UB.

mplanchard 5y ago

Iterating over an enum requires a macro (strum::EnumIter is a popular one), which you’d need in order to ensure the test code automatically covers all cases without needing updates. This does only work when your variants are non-data variants or data variants whose type implements Default, but it does allow you to force yourself to stay in sync. Edit: you might could also do some shenanigans using integers, `as` conversions, and #[repr(u8)], but it seems like it would get nasty and potentially unsafe

Groxx 5y ago
An iterator macro seems fine? You could apply it only during the tests, for example, so it's not like it needs to be exposed in your library.
nmilo 5y ago
An unsafe block is significantly better than the code proposed in the article.
- justin_oaks 5y ago
  I know some people get upset when unsafe is used when there's a "safe" alternative, but unsafe isn't too bad in test code, is it? The concerns of undefined behavior, data races, use-after-free, etc. seem a lot less consequential in test code.
  - nmilo 5y ago
    Unsafe isn't too bad in any code. The point of unsafe is that it is a declaration that the programmer has verified the code is safe. It is certainly easier to verify something along the lines of: unsafe { transmute::<u32, Error>(error_code) } than it is to verify that the weird macro code in the article is correct. There is no data races, use-after-free, etc. in that block, it does exactly what the article needs. To me, Rust programmers seem to have a weird notion that just the word "unsafe" is enough to conjure demons and monsters into otherwise totally normal code.
    - Nullabillity 5y ago
      You'd think so, but that code is far into nasal demon territory. Both because the default byte representation of an enum isn't stable, and because an out-of-bounds enum value (wherever it comes from) is always UB.