> "all enums and integer IDs start at 1"

then whoever takes over maintenance from you and wants to make improvements says "hey, we can add this new v2 feature through the 0x0 which is available for future enhancements"

Unlikely. The way it works is you define your enums like this:

  enum class Color {
    Invalid, // Not a valid value.
    Red,
    Orange,
    Yellow,
    Green,
  };

I think if someone's crazy enough to reclaim a 0 value in an enum or integer ID, then they're probably going to do a lot of damage to the code no matter what you do.

Yeah, pretty much every integer enum I write has `UNKNOWN` or `INVALID` as the zero value. It adds either a `case` or a `default` to every switch and a clause or a `_` to every `match`, but it saves my ass even in non-security-sensitive settings.

That wouldn’t work in situations like this unfortunately. In the ethereum ecosystem the 0x0 address has a special meaning because it is used as the origin of things on chain when they are newly created (they are transferred from 0x0) and often also the destination of things when you want to destroy them (you “burn” something by transferring it to 0x0).

Fun part is as far as I understand this is just a convention and there is nothing intrinsic to 0x0 that makes it different from any other destination address. If someone was to find the private key for which 0x0 is the public half they would have access to a vast amount of stuff that has been transferred there over time. Finding this key is computationally unfeasible however.

Why wouldn’t it work here? Couldn’t you just as easily use address 1 or all ones for the same purpose?

Or use bigger numbers, so enums that get mixed up somehow won’t work.