RFC: rename `int` and `uint` to `intptr`/`uintptr`

[thestinger]

An arbitrarily sized integer type would be provided in std under the name Int. I think encouraging use of an arbitrarily sized integer when bounds are unknown is a much better solution than adding failure throwing overflow checks to fixed-size integers.

[emberian]

I think intptr and uintptr are awful names, but the best alternatives I can come up with is word and sword, which are worse.

Fixed integers of pseudo-arbitrary width are rarely useful.

[Thiez]

Seems to me int and uint are not pointers, so a 'ptr' suffix doesn't make a whole lot of sense. What would the type be of the ~[T].len() and [T, ..n].len()? Surely not uintptr. Perhaps introduce size_t?

I rather like the int and uint types. Why can't they coexist with Int? If they're going to get renamed to something ugly perhaps it would be best to stick with intptr_t and uintptr_t, existing Rust users are going to have to get used to the new stuff anyway, and it'll be easier to remember for those coming from C/C++.

I think the machine-word-sized int and uint are really nice to use as they are at this time. Int could be BigInt or Integer for people who really want arbitrary sized integers, but I'm thinking the vast majority of the time you don't want/need that functionality anyway.

[huonw]

intptr_t and uintptr_t

Why introduce a completely new & (so far) unused naming convention to the language?

[thestinger]

@Thiez: They aren't machine word size, they're pointer-size. On the x32 ABI they will be 32-bit, despite having 16 64-bit integer registers. If you want to use fixed-size integers correctly, you need upper bounds on the size. Fixed-size types named int/uint encourage writing buggy code because it implies they are a sane default rather than just a way to deal with sizes smaller than the address space.

[Thiez]

@thestinger fair point. Perhaps that should change as well? Since we're not really supposed to be messing around with pointers outside of unsafe blocks, perhaps a pointer-size type is deserving of an ugly name. That opens up the option of having int and uint be machine word sized...

[thestinger]

@cmr: I agree they're awful names. We should discourage using fixed-size types only when bounds are unknown. I think you only want these types in low-level code or for in-memory container sizes.

@Thiez: I don't really think word-sized is a useful property. If the upper bound is 32-bit, 32-bit integers will likely be fastest for the use case due to wasting less cache space.

[Thiez]

I realize my suggestion is silly anyway as one would still need a pointer-size variable for array and vector lengths, which is a nice case for int/uint (but not when they're word-sized). Ignore it :)

[1fish2]

I completely agree with @thestinger

A machine-word sized integer means bugs and security holes e.g. because you ran the tests on one platform then deployed on others.

If one of the platforms has 16-bit int like PalmOS, that's too short to use without thinking carefully about it, so the prudent coding style forbids un-sized int and uint. (Actually the PalmOS 68000 ABI is emulated on a 32-bit ARM so it's not clear what's a machine word.)

Hence the strategy of using a pointer-size integer type only in low-level code that requires it, with an ugly name.

[UtherII]

I agree that using int and uint should be discouraged and renaming them to a less straightforward name is better.
I don't know how type inference works but I think it should avoid using them by default too.

[michaelwoerister]

I think that's a good idea. You can't really rely on very much when using int/uint.

I'm not so fond of the names intptr/uintptr. Given that the use cases for these types would be rare, I think they could also be defined in the standard library with more verbose names like PointerSizedInt / PointerSizedUInt. Not much ambiguity there. One could also define other integer types in the same module in the vain of C's uint_fast8_t and uint_least8_t in stdint.h to tackle the "machine word" problem.

[glaebhoerl]

IMHO, the interesting questions are: what type should be used to index into arrays, and what should it be named? Indexing into arrays is pretty common. A pointer-sized type is needed to be able to represent any index. It should presumably be unsigned. I'm not sure if there's much reason to also have a signed version. Expanding to a BigInt on overflow doesn't make much sense here. But wrapping around on over/underflow also doesn't make very much sense, I think. If you want to catch over/underflow and fail!() or similar, you lose a lot (or all) of the performance advantage you might have had over the expand-to-BigInt version. So there's decent arguments in favor of expanding, wrapping, as well as trapping.

I think the strongest argument might be for expanding: negative or larger-than-the-address-space values don't make sense for array indexes, but the array bounds check will already catch that. Meanwhile it's versatile and generally useful for most other situations as well, not just array indexing. The downside is a performance cost relative to a type that wraps on over/underflow. (In the event of a fixed pointer-sized type, the relevant association when naming it should be that it holds any array index, not that it's pointer-sized.)

Whatever this type ends up being and named, it's the one that should be in the prelude.

If someone explicitly needs pointer-sized machine integers for unsafe hackery, those could indeed be named intptr and uintptr and buried in a submodule somewhere.

[bstrie]

Dumb question here, but what's the use of having a signed pointer-sized int at all? Could we get away with having only uintptr (or whatever it ends up being called)?

As for the general idea of this bug, I'm warming to it after seeing how well the removal of float has worked. Having to actually think about the size of my types has been quite illuminating.

[thestinger]

@bstrie: a signed one is needed for offsets/differences (POSIX has ssize_t mostly because they like returning -1 as an error code though! ISO C has ptrdiff_t though)

[1fish2]

@thestinger good point. Subtracting array indexes should yield a signed value.

So to reverse the question, what's the need for an unsigned array index type? Is it feasible to allocate a byte array that takes more than half the address space?

[thestinger]

AFAIK the rationale for unsigned types here is to avoid the need for a dynamic check for a negative integer in every function. A bounds check only has to compare against the length, and a reserve/with_capacity function only has to check for overflow, not underflow. It just bubbles up the responsibility for handling underflow as far as possible into the caller (if it needs to check at all - it may not every subtract from an index).