So for what it’s worth, my preferences are:
First of all, for any names other than int/uint;
Second of all, within that, for names which put the emphasis on the “integer” half of things, rather than on the “pointer” (or whatever) half;
And within that, for intp/uintp in particular. I like it for essentially the same reasons that others gave for liking iptr/uptr: it’s simple and precise. It does still carry some of the same hazard as those did (and which I raised as an objection to them), that people may interpret it as “pointer to int”, or something of that nature. This is a subjective judgment call, but I personally feel that with these names it is now low enough, and that the ‘p’ is more clearly just a modifier on the ‘int’. This also cleanly allows for adding e.g. intr/uintr for register-sized integers, or whatever, in the future.
A close second are intx/uintx; and out of the remainder, I like isize/usize. The only ones I actively dislike are ix/ux, which I feel are too cryptic. (Still better than int/uint, but now only a lesser evil.)
As far as the “consistency” argument goes, I think that one way to think about it is that all of the names “start out” as int16, uint32, etc.; and then we notice that these can be abbreviated to just i16, u32, etc., without significant loss of clarity, because of the implicit separator between the “letters part” and the “numbers part”, which makes it clear that it should be read as a “u” and a “32”, which can then reasonably be intuited to mean “unsigned” and “32 bits”. On the other hand, for intp/uintp or intx/uintx, this doesn’t work, because in ix/ux or ip/up, it’s not clear that the letters are supposed to be taken separately, as “i” and “x”, rather than as a single, indivisible word. Intuiting that “ux” means “unsigned” and “variable bits” takes quite a leap of imagination.
