On: User IDs probably shouldn't be passed around as ints

[mike-cardwell]

Looking at the provided example. Nothing like that has ever happened in any code I've ever written, or I've ever seen written by anybody else, and I have absolutely no fear that I will ever see anything like that happen in any code I write for the rest of my career/life.

So, not a great example, and not a very convincing argument to me to stop using integers.

[tom_ → mike-cardwell]

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.

[JoachimSchipper → tom_]

Agree. I've used 'uint64_t thing_id' in somewhat-similar situations, to make it visually obvious which type you're dereferencing.

(That is, thing_do(foo.other_thing_id) still compiles, but at least it looks wrong.)

[mike-cardwell → tom_]

"Every project I've worked on has had at least one bug of this form, and typically more than one"

Then we have had completely different experiences in software development and are unlikely to agree on the importance of the content in this post.

[tom_ → mike-cardwell]

Quite! It's supposed to be an alternative viewpoint, nothing more.

Thinking about it, maybe I shouldn't have opened with "That's interesting", which here means exactly what it says, but is a phrase sometimes deployed with malicious intent.

[matt_the_bass → tom_]

I like your solution.

[mrob → mike-cardwell]

What arithmetic operations do you realistically expect to do with user ids? You might not make that specific error, but it seems to me that any arithmetic operation is likely to a bug, and giving user ids their own type will catch all of them.