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

71–80 of 80 posts

Re: Enums in Rust – and why they feel better

#71

Post by tialaramex »

sirwhinesalot wrote: post #41

Other people have mentioned it in the comments, but they chose the wrong name for these (as did Swift). They're not enums, they're (pick one): - tagged unions - sum types - algebraic datatypes - variants There are some rust packages that transform rust enums into proper enums, the best one being const_table, or my own table_enum. Java got it right except for bundling the data with the Enum object instead of storing i…

I think I have much more problem with the idea that table_enum is "proper enums" than with the choice to name Rust's sum types enum.

Because Rust is a low bit-banging language, union needs to exist, which I think rules out calling enum "tagged unions" even if that's one possible way to look at the implementation. In a high level language which lacks union types this wouldn't an issue, but Rust is not that language.

Re: Enums in Rust – and why they feel better

#72

Post by tialaramex »

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?

> Rust's Union is for C FFI, right?

No :)

> is there something meaningful that Union is for other than C interop?

Look more closely at the Rust standard library, MaybeUninit is a union.

Re: Enums in Rust – and why they feel better

#73

Post by kazinator »

aeonik wrote: post #56
Shish2k wrote: post #15

Earlier quoted context omitted.

> 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` (Contents of Address part of Register) and `cdr` (Contents of Decrement part of Register) are historical terms from the IBM 704, used in LISP. They're legacy from early computing, not academic jargon.

MacCarthy transformed them into academic jargon in fact. Knowing that the words originated in the IBM 704 idiosyncrasies not found in other machines, he used them anyway in papers about symbolic computation.

Lisp pairs are flexible objects that can be coupled together into shapes and uses that are not lists. car and cdr can mean first and rest, and ANSI Common Lisp [1994] has those synonyms, but there are uses of cons cells where first and rest do not make sense.

MacCarthy must have realized that words that do not invoke any connotations are good for the elements of a flexible pair structure. Choices like first/rest, left/right, top/bottom and others are saddled with semantics that don't match every use.

Programs that need a pair structure in which the two pieces have very specific roles can provide their own synonyms, if their authors feel it makes code more readable.

I seem to recall that Knuth, in TAOCP, at one point, calls the pointers of a binary tree node ALINK and BLINK.

Re: Enums in Rust – and why they feel better

#74

Post by estebank »

Rusky wrote: post #66
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" fo…

I do find myself wanting deref patterns in the rustc codebase often :)

Re: Enums in Rust – and why they feel better

#75

Post by [deleted] »

Rusky wrote: post #66
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" fo…

[deleted]

Re: Enums in Rust – and why they feel better

#76

Post by da39a3ee »

> Other languages like Go do not necessarily have enums, but you can represent enums by using something like this (in Go):

This misses the important point that Go lacks pattern matching -- one uses a switch statement instead -- and the Go compiler lacks the ability to check that all branches have been handled in a switch statement.

Go's concurrency stuff is beautiful. If Go had sum types / Rust-style enums with pattern matching and handled errors as a Result sum type, then it would be a much nicer language.

Re: Enums in Rust – and why they feel better

#77

Post by da39a3ee »

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…

To be fair though, Scala's sum types are a bit of a hack aren't they, or at least pretty cumbersome? Declaring a `sealed abstract class` (or is it trait) and then a bunch of case classes syntactically disconnected from the sealed abstract thing that defines the sum type.

Re: Enums in Rust – and why they feel better

#78

Post by mattstir »

sirwhinesalot wrote: post #70
mattstir wrote: post #67

Earlier quoted context omitted.

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.

I mean... yeah, that's exactly why Rust has tagged unions as well... both are useful in the right contexts, but tagged unions are easier to work with in general. That doesn't mean that (untagged) unions should be safe to work with though, because they can't be.

Re: Enums in Rust – and why they feel better

#79

Post by sc22 »

da39a3ee wrote: post #77
Shish2k wrote: post #15

Earlier quoted context omitted.

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

To be fair though, Scala's sum types are a bit of a hack aren't they, or at least pretty cumbersome? Declaring a `sealed abstract class` (or is it trait) and then a bunch of case classes syntactically disconnected from the sealed abstract thing that defines the sum type.

Scala 3 has enums, which can also serve as ADts: https://docs.scala-lang.org/scala3/reference/enums/enums.htm...

Re: Enums in Rust – and why they feel better

#80

Post by da39a3ee »

sc22 wrote: post #79
da39a3ee wrote: post #77

Earlier quoted context omitted.

To be fair though, Scala's sum types are a bit of a hack aren't they, or at least pretty cumbersome? Declaring a `sealed abstract class` (or is it trait) and then a bunch of case classes syntactically disconnected from the sealed abstract thing that defines the sum type.

Scala 3 has enums, which can also serve as ADts: https://docs.scala-lang.org/scala3/reference/enums/enums.htm...

Ah right, thanks. I've only used Scala 2. To what extent do Scala 3 enums give you what you want in the way of sum types? E.g. compared to Rust enums?
Post reply on HN