That's interesting. Every project I've worked on has had at least one bug of this form, and typically more than one, where the integer-type indexes into a table

That's interesting. Every project I've worked on has had at least one bug of this form, and typically more than one, where the integer-type indexes into a table of integer-type IDs have got mixed up with the integer-type IDs. You might be surprised how much of a pain in the arse it is to even realise these bugs exist, because during development and initial tests these tables have a nasty habit in many situations of containing IDs that are the same as the index. And when everything is an int, or similar, fixing them can be quite painful too. It just takes one bug in one function for a set of subtly broken workarounds and/or misunderstandings to spread throughout the code. Lots of places where functions take an "id" and then pass it into a function that takes an "index", or vice versa... just what was the intention here? :( This shit is the worst kind of bug. My usual solution: struct ThingID {uint64_t id;}; typedef struct ThingID ThingID; struct OtherThingID {uint64_t id;}; typedef struct OtherThingID OtherThingID; And that's it. When at all syntactically inconvenient, it's a sign you're possibly doing the wrong thing.