Hacker News Reader

Comment by AnimalMuppet | Hacker News Reader

I'm not sure I understand your argument. You're saying that you can't really use enums for field numbers. And let's say that you're absolutely correct about that.

It still seems to me that you're addressing a completely separate issue from having a specific field that is an enum - not an enum of a field number, but an enum of something else, like encryption algorithm or SHA type or something.

Am I missing your point?

View on HN

I’m pointing out that proto’s enums are wrappers around proto field numbers, which are numerical ids for proto message fields that enable forward/backward compatibility across proto message version changes. These field numbers are necessarily sparse but don’t even need to be assigned sequentially, and in fact, because of the leaked implementation details from the internal field number range you have to assume they are non-sequential. So field numbers are sparse, which makes them non-enumerable even though they’re represented with numeric tags.

Hence, proto enums are essentially non-enumerable wrappers around numeric values. And this is (almost certainly) why Golang’s enums are structured the same way, as transparent wrappers around values that are not necessarily sequential or enumerable.

But why is sequential a requirement? That is, in C++ I can have an enum like

  enum mask {
    BIT_0 = 0x1,
    BIT_1 = 0x2,
    BIT_2 = 0x4,
    BIT_3 = 0x8,
    NIBBLE_0 = 0xF,
  ...
  };

C++ does sparse enums just fine. Are you saying that those are not "real" enums because their sparse? Or that C++ doesn't have "real" enums because it allows that? Or what?

Reply on news.ycombinator.com