Clearly your gender field is a boolean. Which means it can be either true, false, null, or undefined. Except in javascript where for some reason it can sometimes be NaN, but only when you try to compare two people.
My gender is
{ toString: ()=>{String.prototype.toString = ()=>">:3"; return ":3";} }
Even booleans take up 8 bits. And that’s a lot of wasted space.
That’s why you use bitarrays and bitflags instead when you need more than just one or two arguments for a function.
Only if it’s performance sensitive. Otherwise you’re wasting programmer time both writing and reading the code, and you’ve made it less maintainable with more complexities where bugs can creep in.
The vast majority of the time you can afford a few wasted bits.
Honestly though I don’t quite understand why a compiler couldn’t optimise this process. Like it knows what a boolean is, surely it could reduce them down to bits.
Gender is obviously a signed byte.
Gender is a struct
struct Gender { byte binaryBias; ///Determines male (+) or female (-) bias if present ubyte binaryAm; ///Determines the amount of binary gender(s) present bool isTrans; ///True if assigned at birth gender does not equal with current one ubyte xenoAm; ///Determines the amount of xenogender uint xenoGen; ///Xenogender selection, 0 if not applicable Sex* sex; ///Pointer to the person's current sex }
Now this is a gender definition I can get behind. None of that string/enum crap, just raw data.