[randomdata]

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]

> 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]

> 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]

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

[randomdata]

> I mean more in the sense of "where did you get this definition from."

In other words, you want to have a conversation with someone else by proxy? If that's the case, why not just go talk the other people you'd really prefer to talk to?

> I'm still not seeing a difference

There is no difference. I recant what I said. This (strangely, undocumented in the above link) functionality does, in fact, provide use of enums.

Curious addition to the language. Especially when you consider how unsafe enums are. When would you ever use it? It is at least somewhat understandable in C++ as it may be helpful to "drop down" to work with the standard enum construct in some migratory situations, but when do you use it in Rust?

[modulared]

> Why not just go talk the other people you'd really prefer to talk to?

sorry, I didn't mean to be so argumentative or negative. (The "You'll have to ask the Rust community. Rust lacks enums." did get me a little annoyed :p)

> This (strangely, undocumented in the above link) functionality does, in fact, provide the use of enums.

That link was from "the rust book" which is primarily is for learning rust. For more technical info the referenced is used https://doc.rust-lang.org/reference/items/enumerations.html

> When would you ever use it?

I assume (like you said for c++) a good reason would be for c/c++ interoperate, but it also probably makes things like serialization easier. Sometimes you just need a number (e.g. indexing an array) and it's simpler to be able to cast then have a function that goes from enum -> int.

> Especially when you consider how unsafe enums are.

Do note though, going from int -> enum is an unsafe op which would require `std::mem::transmute`.

[randomdata]

> sorry, I didn't mean to be so argumentative or negative.

Thanks, but I had no reason to think that the output of software has human qualities.

> That link was from "the rust book" which is primarily is for learning rust.

Learn Rust by keeping features of the language a secret? Intriguing.

> a good reason would be for c/c++ interoperate

I'm not sure that's a good reason. C++ doing it is questionable to begin with, but at least you can understand how a bad idea might have made it in many years ago when we didn't know any better.

> it also probably makes things like serialization easier.

It would, except you would never want to serialize the product of an enum as it means your program becomes forever dependent on the structure of the code. I mean, sure, you can remove the enum later if you are to change the code, so you're not truly stuck, but that kind of defeats the purpose. You may as well do it right the first time.

Enums are inherently unsafe. That you have to be explicit about converting the union to an integer at least gives some indication that you are doing something unsafe. It is not so unusual that Rust allows some kind of "escape hatch" to get at the actual memory. What is interesting, though, is that it also allows manipulation of what values are assigned by the enumerator as a first-class feature, which suggests that it promotes this unsafe behaviour. This is what is surprising and what doesn't seem to serve a purpose.