Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enums in Rust – and why they feel better

shuttle.rs

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Enums in Rust – and why they feel better

#61

Post by hurril »

flohofwoe wrote: post #16
hurril wrote: post #4

Earlier quoted context omitted.

While I agree with you, I can understand going with enum so that they don't scare away the C and C++ crowd with being too fartsy with theoretic stuff.

It is especially confusing for C and C++ coders, because Rust enums are a completely different thing than C enums, which makes the naming choice worse than just inventing a new name. Better names would be "tagged union" (which is spot-on descriptive - because it *is* a union with a tag slapped on - but "tagged_union" of course is a bit unwieldy as keyword) or "variant" (which is the name for that thing in C++ and els…

I agree with you! I dislike the name enum and really like how F# does it. In F#, everything is type and what kind of type you create comes down to the type construction literal you use.

` (* enum ) type 'a Option = Some of 'a | None `

( struct - well: record. *) type Company = { Name : string Age : int }

Fudge. No idea how to format that in HN.

Re: Enums in Rust – and why they feel better

#62

Post by xboxnolifes »

Shish2k wrote: post #15
hurril wrote: post #3

> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…

> Haskell, Scala, F#, OCaml, etc. Rust is the first not-weirdass-academic-wtf language to have these features ;) (I love functional programming and apply the functional approach no matter what language I’m using - but why is it that functional languages are always so deeply down the academic rabbithole that they think eg “car” and "cdr” are intuitive names for “retrieve the first element of a list” and “retrieve the…

car and cdr are no more confusing then the historical C functions that turn entire sentences into initialisms. And surely nobody would call C an academic language in this context.

Re: Enums in Rust – and why they feel better

#63

Post by chlorion »

hurril wrote: post #3

> A commonly said piece of feedback from someone who's learning Rust as a second language tends to be that enums are far better supported in Rust than any other language. This is nonsense. I doubt that this is common feedback and it is just not correct that it is far better supported in Rust than in any other language. Why would anyone say that? Rust pretty much has support for ADTs, sum types and product types. Just…

>Why would anyone say that?

Most people have not had any exposure to functional programming languages or functional programming in general. When they say "any other language" they mean, any other language that they have used or know anything about I guess.

This is one of those cases where we fail to realize that other people's reality is totally different than ours. Everyone does this all of the time, not just you specifically to be clear, this is a limitation in our brains.

Re: Enums in Rust – and why they feel better

#64

Post by binary132 »

steveklabnik wrote: post #30
flohofwoe wrote: post #23

Earlier quoted context omitted.

TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)

Don’t forget rust also has unions. Not using the name “union” for a feature that’s different than unions doesn’t feel “obviously wrong” to me.

Rust's Union is for C FFI, right?

Why not call Enum Union, and the FFI one CUnion or something? Like, is there something meaningful that Union is for other than C interop? Isn't it functionally identical to a tagged union in every other respect?

Re: Enums in Rust – and why they feel better

#65

Post by steveklabnik »

binary132 wrote: post #64
steveklabnik wrote: post #30

Earlier quoted context omitted.

Don’t forget rust also has unions. Not using the name “union” for a feature that’s different than unions doesn’t feel “obviously wrong” to me.

Rust's Union is for C FFI, right? Why not call Enum Union, and the FFI one CUnion or something? Like, is there something meaningful that Union is for other than C interop? Isn't it functionally identical to a tagged union in every other respect?

C FFI is a very useful thing, sure, but I don’t think it’s exclusive to that. It’s a nice primitive to have access to. I think Rust would feel weird with tagged unions and not untagged ones, just like having both sum and product types are good.

Re: Enums in Rust – and why they feel better

#66

Post by Rusky »

sshine wrote: post #17

Better enums, but not better ADTs. I didn’t write a lot of compilers in Rust yet, but I find it limiting that you can’t pattern match across a Box , and all ASTs require boxing for recursive references.

Often, when you have a compiler-y recursive ADT, you will want to allocate the individual nodes in an arena rather than from the global allocator as with Box. And at that point, you can use references (with the lifetime of the arena) rather than Boxes, and you can pattern match across those.

(Note that this doesn't work if your "arena" is just a Vec, which is something people have sort of hijacked the term "arena" for. It needs to be an arena that doesn't reallocate its contents on growth, something like https://docs.rs/bumpalo/latest/bumpalo/, in order to hand out references that live across allocations like this.)

Re: Enums in Rust – and why they feel better

#67

Post by mattstir »

sirwhinesalot wrote: post #42
steveklabnik wrote: post #30

Earlier quoted context omitted.

Don’t forget rust also has unions. Not using the name “union” for a feature that’s different than unions doesn’t feel “obviously wrong” to me.

The right solution was to make union safe with an opt-in way to make it unsafe IMO.

The thing is that accessing an untagged union's data is just inherently unsafe. Say you made a union with a `u8` field and a `bool` field. If you had an instance of it and set its value to `5`, that's just not a valid `bool`. Hence the requirement of `unsafe`; you need to tell the compiler that you _know_ it's a valid value at the point you're accessing it.

Re: Enums in Rust – and why they feel better

#68

Post by mattstir »

binary132 wrote: post #55
flohofwoe wrote: post #23

Earlier quoted context omitted.

TBH it's kinda funny how they narrowed it down to two options and then went with the "obviously" wrong option (also to get C++ programmers on board, wouldn't the obvious name not be "variant"? I really wonder how that decision making progress looked like :)

"C++ calls it variant." "OK, let's not go with that then" "C calls it union" "OK, we DEFINITELY can't call it that"

Rust already has things called unions, which are C-style unions. Using the same word for two different things would definitely have been more confusing, not less...

Re: Enums in Rust – and why they feel better

#70

Post by sirwhinesalot »

mattstir wrote: post #67
sirwhinesalot wrote: post #42

Earlier quoted context omitted.

The right solution was to make union safe with an opt-in way to make it unsafe IMO.

The thing is that accessing an untagged union's data is just inherently unsafe. Say you made a union with a `u8` field and a `bool` field. If you had an instance of it and set its value to `5`, that's just not a valid `bool`. Hence the requirement of `unsafe`; you need to tell the compiler that you _know_ it's a valid value at the point you're accessing it.

Then make them tagged, that's what rust enums are, tagged unions, except they're called enums instead of unions.
Post reply on HN