Using enums to represent state in Rust

Post by hurril » Fri, Sep 22, 2023, 4:32 PM UTC

duped wrote: post #40

hurril wrote: post #37

Earlier quoted context omitted.

Then what does this mean? let x: u8 = E::Rest(0).into(); let y: E = x.into();

Bad example, that should panic (in a perfect world it should be a compile error). The invariant of the type is that `E::Rest` cannot hold zero.

Post by GalaxySnail » Fri, Sep 22, 2023, 5:15 PM UTC

qsort wrote: post #9

the__alchemist wrote: post #6

Earlier quoted context omitted.

I joke to myself that I program with "struct and enum-oriented programming". I got it from Rust, but apply it to Python too. (Python enums aren't as ergonomic, and they can't wrap values, but they're a start)

Python's equivalent of Rust's Enums would be the __match_args__ machinery rather than enums themselves, ironically. They aren't as ergonomic or type-safe, and rather surprisingly the match statement is not an expression in Python's grammar, but regardless of its problems the match statement is very powerful, even more so than static equivalents.

Post by twic » Fri, Sep 22, 2023, 5:43 PM UTC

Arnavion wrote: post #36

flohofwoe wrote: post #11

Earlier quoted context omitted.

I just wish Rust wouldn't have called those things 'enums' but 'tagged unions', would have saved us C peasants a lot of confusion when encountering them first ;)

That would still be technically misleading, since enums don't necessarily have tags due to niche optimization. Eg `Option` is an enum but `Option >` does not have any tags; it uses the content being zero to represent None since `Box ` cannot be zero. Also, Rust does have actual tagged unions for C interop that you have to define yourself as a `struct` with an int field and a `union` field, just like in C.

Post by twic » Fri, Sep 22, 2023, 5:53 PM UTC

duped wrote: post #26

Enums are fantastic. But they could be better! One thing Rust could really use are anonymous unions (A | B |C instead of E::A(A), E::B(B), E::C(C)). They are to enums what tuple types are to structs. Another thing that a new language designer might consider is a mechanism to control the layout. For example say I have a pair of nested enums enum A { A0(B), ... A15(B), } enum B { B0, ... B15, } The outer enum A can be…

Post by bombela » Fri, Sep 22, 2023, 6:18 PM UTC

goku12 wrote: post #24

pdpi wrote: post #4

I kind of consider algebraic data types (the combination of this style of enum (sum types) and structs (product types)) paired with pattern matching as the core feature set that any modern language must support. It makes for really simple, easy to follow code that’s much less error prone than the alternatives.

I sometimes wish Rust had combined structs and enums into a single concept - same an enum. Structs would have been unnecessary. The compiler can simply avoid the tag or the union when a pure struct or a pure (c-type) enum is required, respectively.

  pub enum Foo {
      Foo { a: i32 },
  }
  
  impl Foo {
      pub fn new() -> Self {
        Foo::Foo { a: 42 }
      }
  
      pub fn get_a(Foo::Foo{a}: &Self) -> &i32 {
          a
      }
  }

  example::Foo::new:
          mov     eax, 42
          ret
  
  example::Foo::get_a:
          mov     rax, rdi
          ret