4 ms·

You'll have to ask the Rust community. Rust lacks enums. Go, however, most definitely has enums (and exceptions too!). type E int const ( A E =

You'll have to ask the Rust community. Rust lacks enums. Go, however, most definitely has enums (and exceptions too!). type E int const ( A E = iota B C ) It's funny how people who have clearly never even looked at Go continually think they are experts in it. What causes this strange phenomena?

jjice 2y ago
Go has a way to implement enums - I'll give you that. Rust does have enums though: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html They can have values like sum types, or not.
- randomdata 2y ago
  > Rust does have enums though It does not. You'll notice that if you read through your link. A tag-only union is not the same thing, even if you can find some passing similarities. If you mean it has enums like the Democratic People's Republic of Korea has a democracy, then sure, it does have enums in that sense. I'm not sure that gives us anything meaningful, though. If we're being honest, sum types are the better solution. Enums are hack for type systems that are too limited for anything else. They are not a feature you would add if you already have a sufficient type system. It's not clear why Rust even wants to associate itself with the hack that are enums, but your link shows that its author has a fundamental misunderstanding of what enums even are, so it may be down to that. To be fair, Swift made the same mistake, but later acknowledged it. It is interesting that Rust has chosen to double down instead.
  - jjice 2y ago
    > A tag-only union is not the same thing, even if you can find some passing similarities Why not? Seems to function the same way.
    - randomdata 2y ago
      Enums produce values. Tag-only unions 'produce' types (without values). Realistically, there isn't a whole lot of practical difference. They were both created to try and solve much the same problem. As before, I posit that there is no need for a language to have both. You can do math on enum values, but that is of dubious benefit. In theory, tag-only unions provide type safety, whereas enums are just values so there is no inherit safety... But, as you probably immediately recognized a few comments back, with some static analysis you can take the greater view, type E int const ( A E = iota B C ) and invent something that is just as useful as proper type safety. All the information you need is there. So, in reality, that need not even be significant. But, technically there is a difference. Values and types are not the same thing.
      - modulared 2y ago
        > Enums produce values. Tag-only unions 'produce' types (without values). Source? Is this something that is widely accepted, or just how you think enums should be defined. My understanding is you are saying (using c++ as an example since it has both types) an `enum` is a "true" enum, while an `enum class` somehow isn't?
        randomdata 2y ago
        > Source? To which language? > `enum` is a "true" enum, while an `enum class` somehow isn't? No. Enums are used in both cases. The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. This differs from Rust. Rust does not use enums. It relies on the type itself to carry all the information. C++ enum classes could have done the same, so it is not clear why they chose to use enums, but perhaps for the sake of familiarity or backwards compatibility with the regular enum directive?
        modulared 2y ago
        > To which language? I mean more in the sense of "where did you get this definition from." > The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same. #[repr(u8)] enum Words { Foo = 0, Bar, Baz, } const _: () = { assert!(Words::Foo as u8 == 0); assert!(Words::Bar as u8 == 1); assert!(Words::Baz as u8 == 2); }; vs enum class Words : uint8_t { Foo = 0, Bar, Baz }; static_assert(static_cast<uint8_t>(Words::Foo) == 0); static_assert(static_cast<uint8_t>(Words::Bar) == 1); static_assert(static_cast<uint8_t>(Words::Baz) == 2);

jjice 2y ago

Go has a way to implement enums - I'll give you that. Rust does have enums though: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html They can have values like sum types, or not.

randomdata 2y ago
> Rust does have enums though It does not. You'll notice that if you read through your link. A tag-only union is not the same thing, even if you can find some passing similarities. If you mean it has enums like the Democratic People's Republic of Korea has a democracy, then sure, it does have enums in that sense. I'm not sure that gives us anything meaningful, though. If we're being honest, sum types are the better solution. Enums are hack for type systems that are too limited for anything else. They are not a feature you would add if you already have a sufficient type system. It's not clear why Rust even wants to associate itself with the hack that are enums, but your link shows that its author has a fundamental misunderstanding of what enums even are, so it may be down to that. To be fair, Swift made the same mistake, but later acknowledged it. It is interesting that Rust has chosen to double down instead.
- jjice 2y ago
  > A tag-only union is not the same thing, even if you can find some passing similarities Why not? Seems to function the same way.
  - randomdata 2y ago
    Enums produce values. Tag-only unions 'produce' types (without values). Realistically, there isn't a whole lot of practical difference. They were both created to try and solve much the same problem. As before, I posit that there is no need for a language to have both. You can do math on enum values, but that is of dubious benefit. In theory, tag-only unions provide type safety, whereas enums are just values so there is no inherit safety... But, as you probably immediately recognized a few comments back, with some static analysis you can take the greater view, type E int const ( A E = iota B C ) and invent something that is just as useful as proper type safety. All the information you need is there. So, in reality, that need not even be significant. But, technically there is a difference. Values and types are not the same thing.
    - modulared 2y ago
      > Enums produce values. Tag-only unions 'produce' types (without values). Source? Is this something that is widely accepted, or just how you think enums should be defined. My understanding is you are saying (using c++ as an example since it has both types) an `enum` is a "true" enum, while an `enum class` somehow isn't?
      - randomdata 2y ago
        > Source? To which language? > `enum` is a "true" enum, while an `enum class` somehow isn't? No. Enums are used in both cases. The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. This differs from Rust. Rust does not use enums. It relies on the type itself to carry all the information. C++ enum classes could have done the same, so it is not clear why they chose to use enums, but perhaps for the sake of familiarity or backwards compatibility with the regular enum directive?
        modulared 2y ago
        > To which language? I mean more in the sense of "where did you get this definition from." > The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same. #[repr(u8)] enum Words { Foo = 0, Bar, Baz, } const _: () = { assert!(Words::Foo as u8 == 0); assert!(Words::Bar as u8 == 1); assert!(Words::Baz as u8 == 2); }; vs enum class Words : uint8_t { Foo = 0, Bar, Baz }; static_assert(static_cast<uint8_t>(Words::Foo) == 0); static_assert(static_cast<uint8_t>(Words::Bar) == 1); static_assert(static_cast<uint8_t>(Words::Baz) == 2);