Mirror of forum.nim-lang.org

9044 :: how to make a enum with wrapped ordinals

• solomonthewise (orginal) [2022-03-25T18:34:15+01:00] view original

  I was working on a connect 4 app and I created a enum called player. with two different values. I want the ability to easy swap the value of player using inc(p) but when I do that I get a overflow error. This makes enums a lot less useful for me. Is there a way to have a enum type that wraps back around?

---

• doofenstein (orginal) [2022-03-25T18:55:17+01:00] view original

  I don't think there's a function in the standard library for this, how about this:

  proc incWithWrap[T: enum](v: var T) =
    if v == high(T):
      v = low(T)
    else:
      inc v
  Run

---

• solomonthewise (orginal) [2022-03-25T18:59:08+01:00] view original

  thanks, I still haven't figured out generics yet so this is very helpful. I'm wondering why this isn't the standard behavior for enums though. Every single time I've created a enum I've wanted it it wrap

---

• Araq (orginal) [2022-03-25T20:36:00+01:00] view original

  And I have never wanted it to wrap in my entire life. In fact, saturated arithmetic is often more useful and equally unsupported.

  You can also use type T = distinct uint8 and .borrow the inc operator so that you get a new type that wraps.

---

• exelotl (orginal) [2022-03-25T20:56:20+01:00] view original

  I think it probably shouldn't be the default? Say there's a case where I don't want an enum to wrap, and I write some code that accidentally increments it beyond its maximum value. If it wraps by default, then I've just introduced silently buggy behaviour into my program, while a fatal error would have allowed me to hunt down the issue a lot quicker.

  Additionally, if I compile with -d:danger, the compiler can remove the error checking for better performance, but it couldn't remove the wrapping logic because that would break the cases where I intentionally let it wrap.

  That said, I agree that wrapping versions of inc and dec (and succ and pred) are a pretty common requirement so it would make sense to have something like that in the stdlib.

---