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

41–50 of 80 posts

Re: Enums in Rust – and why they feel better

#41

Post by sirwhinesalot »

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 it in separate tables.

Having said that, I could not be happier that sum types have entered the mainstream.

Re: Enums in Rust – and why they feel better

#42

Post by sirwhinesalot »

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.

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

Re: Enums in Rust – and why they feel better

#43

Post by flohofwoe »

Liquid_Fire wrote: post #38
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 :)

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

Boost as "stdlib prototype" had that type much earlier though, going back to 2002 or so:

https://www.boost.org/doc/libs/1_64_0/doc/html/variant.html

The name and concept was also common enough to that I used "Variant" in my own C++ utility class collection around 2005 or so.

Re: Enums in Rust – and why they feel better

#44

Post by ReleaseCandidat »

Liquid_Fire wrote: post #38
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 :)

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

Yes, but `boost::variant` existed since 2004 https://www.boost.org/users/history/version_1_31_0.html

Re: Enums in Rust – and why they feel better

#45

Post by steveklabnik »

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.

In concrete terms, what would that look like?

Re: Enums in Rust – and why they feel better

#46

Post by junon »

rgoulter wrote: post #12

The term "Newtype" more specifically describes a wrapper around a single type. It's like an alias. It's incorrect to describe an enum with two variants as a 'newtype'. I think the example was misunderstood from https://rust-unofficial.github.io/patterns/patterns/behaviou... (which uses Password, but doesn't use an enum with two variants). The use of enums in the example is fine; but it's not a "newtype".

More specifically the newtype pattern is mostly so that you can implement foreign traits on foreign types.

You can't normally do this since there's a high risk of duplicate implementations, so by enforcing only local types/foreign traits or foreign types/local traits (and of course local/local types and traits), this duplication doesn't occur - there's only ever one implementation of a trait per type, and the ownership of those implementations is very clear and we'll defined.

The newtype pattern simply makes a "local" type that wraps a foreign type, allowing you to implement the foreign trait on the new local type, and forwarding calls of the trait methods to the inner type - all while maintaining the single trait impl and ownership constraints rust imposes.

Further, given all of the compiler optimizations that happen, newtypes are effectively free.

For those who haven't seen it, this is what newtype looks like:

    use some::ForeignType;
    
    struct LocalType(ForeignType);
As the parent comment states, it has nothing to do with enums.

Re: Enums in Rust – and why they feel better

#47

Post by stmblast »

rgoulter wrote: post #12

The term "Newtype" more specifically describes a wrapper around a single type. It's like an alias. It's incorrect to describe an enum with two variants as a 'newtype'. I think the example was misunderstood from https://rust-unofficial.github.io/patterns/patterns/behaviou... (which uses Password, but doesn't use an enum with two variants). The use of enums in the example is fine; but it's not a "newtype".

Hey, author here! Thanks for the feedback.

I agree that this could have been worded better - I'll make an adjustment to change this.

Re: Enums in Rust – and why they feel better

#48

Post by ReleaseCandidat »

junon wrote: post #46
rgoulter wrote: post #12

The term "Newtype" more specifically describes a wrapper around a single type. It's like an alias. It's incorrect to describe an enum with two variants as a 'newtype'. I think the example was misunderstood from https://rust-unofficial.github.io/patterns/patterns/behaviou... (which uses Password, but doesn't use an enum with two variants). The use of enums in the example is fine; but it's not a "newtype".

More specifically the newtype pattern is mostly so that you can implement foreign traits on foreign types. You can't normally do this since there's a high risk of duplicate implementations, so by enforcing only local types/foreign traits or foreign types/local traits (and of course local/local types and traits), this duplication doesn't occur - there's only ever one implementation of a trait per type, and the ownersh…

> More specifically the newtype pattern is mostly so that you can implement foreign traits on foreign types.

For some definition of "mostly". I use most of my newtypes neither in Rust nor in Haskell to implement traits, but most of the time to declare - newtypes ;) that wrap other (primitive) types.

Re: Enums in Rust – and why they feel better

#49

Post by layer8 »

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.

Some schema languages call it “choice”.

Re: Enums in Rust – and why they feel better

#50

Post by eigenspace »

An interesting aspect of sum types (what Rust calls enums) is that you can implement them in the language as a library if you have real unions, but not vice-versa.

Here's my example of sum types being implemented in julia as a regular package: https://github.com/MasonProtter/SumTypes.jl

Post reply on HN