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

31–40 of 80 posts

Re: Enums in Rust – and why they feel better

#31

Post by Georgelemental »

noam_k wrote: post #22
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.

I think what you want is to enable box_patterns[0]. I have no idea why it isn't stable yet. [0] https://doc.rust-lang.org/beta/unstable-book/language-featur...

The Rust language team wants a more general solution that also works with types like `Arc`, instead of hardcoding a special case for `Box` into the language. This is generally called "deref patterns." But there are tricky open design questions, so the effort is stalled until someone comes up with a proposal addressing them

Re: Enums in Rust – and why they feel better

#32

Post by jowea »

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…

Maybe it's because you can use a Rust enum like in C by doing a field-less or unit-only enum?

Re: Enums in Rust – and why they feel better

#33

Post by pjmlp »

CodesInChaos wrote: post #21
pjmlp wrote: post #7

Earlier quoted context omitted.

Java enums are also quite powerful versus what C, C++ and C# can do. They are real objects, can have associated data and methods. So if they are surprised by Rust, haven't learnt Java properly

Java enums store the associated data once per option, while Rust enums store it per value. So they're very different. You couldn't model Rust's `Option` or `Result` as a java enum.

Sure, I didn't say it was the same, only they are more powerful than C, C++ and C#.

Re: Enums in Rust – and why they feel better

#34

Post by nfriedly »

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…

I might say something like that. My background is a lot of JavaScript and a little bit of other things like c++, python, Ruby, php, etc.

To me, enums are one of the great things about Rust, and I wish I had the same capabilities in JavaScript and other languages.

Re: Enums in Rust – and why they feel better

#35

Post by crvdgc »

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…

I'm sure you know car and cdr are named for historic reasons and they are not featured in ML family languages as listed above. But coming back to the name of "sum type", I find it very potent to be used with "product type" to reason about Algebraic Data Type's properties, like a * (b + c) = a * b + a * c and don't understand why it's often avoided to be called in this way in "mainstream" programming languages.

Re: Enums in Rust – and why they feel better

#36

Post by andrybak »

CodesInChaos wrote: post #21
pjmlp wrote: post #7

Earlier quoted context omitted.

Java enums are also quite powerful versus what C, C++ and C# can do. They are real objects, can have associated data and methods. So if they are surprised by Rust, haven't learnt Java properly

Java enums store the associated data once per option, while Rust enums store it per value. So they're very different. You couldn't model Rust's `Option` or `Result` as a java enum.

> You couldn't model Rust's `Option` or `Result` as a java enum.

For reference, they can be modeled as a "sealed" class since Java 17. https://openjdk.org/jeps/409

Prior to Java 17, sealed classes feature can be partially recreated via private constructors in the super classes. This approach forces you to put all classes in a single Java file, which can be awkward to navigate.

Re: Enums in Rust – and why they feel better

#37

Post by pjmlp »

ongy wrote: post #9
pjmlp wrote: post #7

Earlier quoted context omitted.

Java enums are also quite powerful versus what C, C++ and C# can do. They are real objects, can have associated data and methods. So if they are surprised by Rust, haven't learnt Java properly

I Haven't used java in ages. Though from a quick search, it's still just scalar/unary values. Rhough one of the better implementations of those. But the big advantage of the more sum type Style enums rust provides is the ability to nest values in them while preserving type safety guarantees. So I still see them as miles better as a language concept.

Still, better than C, C++ and C#, which was my point.

For the real deal, there are sealed classes now, modeled on how Scala does it.

Re: Enums in Rust – and why they feel better

#38

Post by Liquid_Fire »

flohofwoe wrote: post #23
kibwen wrote: post #8

Earlier quoted context omitted.

In early Rust, the keyword was `tag`. In order to improve familiarity with C++ programmers, bikeshedding raged between `enum` and `union` for years before finally landing on the former.

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

> to get C++ programmers on board, wouldn't the obvious name not be "variant"?

The use of "enum" in Rust predates the standardization of C++17, where std::variant was introduced.

Re: Enums in Rust – and why they feel better

#39

Post by math_dandy »

bruce343434 wrote: post #2

I always hated the name. You're not enumerating anything. You are picking a variant, encoding a choice. Maybe "sum type" is too "monad", but surely "variant record" or even "variant" would have been a better name.

OCAML uses the terminology “(Polymorphic) Variant” for this kind of thing. Since OCAML is awesome, I consider this a strong precedent.

Re: Enums in Rust – and why they feel better

#40

Post by dgb23 »

bruce343434 wrote: post #2

I always hated the name. You're not enumerating anything. You are picking a variant, encoding a choice. Maybe "sum type" is too "monad", but surely "variant record" or even "variant" would have been a better name.

They are tagged unions right?

"Enum" is not the worst term here. In fact you are enumerating the variants. It's only slightly misleading. It implies that you're comparing an integer.

There is an actual enum backing it to encode the choice (tag), and a union to encode the data (if it has data). Or at least that's what I would expect.

"Variant" is used in Rust lingo to name the variants, not the whole type.

Post reply on HN