# Int v UInt

**URL:** <https://discourse.julialang.org/t/int-v-uint/11484>\
**Category:** General Usage\
**Created:** [June 6, 2018, 7:34pm UTC](https://discourse.julialang.org/t/int-v-uint/11484 "2018-06-06T19:34:30Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![00vareladavid](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/00vareladavid/32/23521_2.png) [@00vareladavid](https://discourse.julialang.org/u/00vareladavid)\
**Post date:** [June 6, 2018, 7:34pm UTC](https://discourse.julialang.org/t/int-v-uint/11484/1 "2018-06-06T19:34:30Z")

</div>

Is there any reason Int, and not UInt, is the canonical type for sizes? E.g. `typeof(length(some_array))` is Int.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [June 6, 2018, 7:41pm UTC](https://discourse.julialang.org/t/int-v-uint/11484/2 "2018-06-06T19:41:13Z")

</div>

Unrelated to Julia, but here is the C++ library Eigen’s answer to that question:

> At a first glance it is indeed very tempting to use an unsigned type for values that are expected to be positive or zero. However, unsigned types relies on modulo 2^k arithmetic, which is definitely not what we want here. Moreover, in many places we can have negative indices and offsets. Mixing signed and unsigned integers is costly, error prone, and highly correlated to bugs. As a result, it is much simpler and safer to use signed integers everywhere, and reserve the usage of unsigned integers for bitwise manipulation and modulo 2^k arithmetic.
> 
> Hm… but the STL use unsigned integers everywhere. Right, but this has been acknowledge as a mistake by several members of the C++ standardization committee and C++ experts (Bjarne Stroustrup, Herb Sutter, Chandler Carruth, Eric Niebler, etc.).

[http://eigen.tuxfamily.org/index.php?title=FAQ#Why\_Eigen.27s\_API\_is\_using\_signed\_integers\_for\_sizes.2C\_indices.2C\_etc..3F](http://eigen.tuxfamily.org/index.php?title=FAQ#Why_Eigen.27s_API_is_using_signed_integers_for_sizes.2C_indices.2C_etc..3F)

---

<div class="post-metadata">

**Author:** ![simonbyrne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonbyrne/32/19_2.png) [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)\
**Post date:** [June 6, 2018, 7:51pm UTC](https://discourse.julialang.org/t/int-v-uint/11484/3 "2018-06-06T19:51:53Z")

</div>

Also unsigned integers don’t buy you that much: you only get a factor of 2 increase. Perhaps in the 32-bit days there was an argument to be made (e.g. so I can have 4GB instead of 2GB arrays), but now that 64-bit platforms are basically standard there are very few cases where integers between 2^63 and 2^64 are especially useful.

---

<div class="post-metadata">

**Author:** ![00vareladavid](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/00vareladavid/32/23521_2.png) [@00vareladavid](https://discourse.julialang.org/u/00vareladavid)\
**Post date:** [June 6, 2018, 8:31pm UTC](https://discourse.julialang.org/t/int-v-uint/11484/4 "2018-06-06T20:31:13Z")

</div>

Excellent reference! Basically: I will use negative values elsewhere in my code and mixing signed/unsigned easily introduces bugs, so it is preferable to maintain a uniform representation across the codebase.

I always used unsigned values so as to avoid domain errors, but an assert can easily take care of that too.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [June 6, 2018, 9:06pm UTC](https://discourse.julialang.org/t/int-v-uint/11484/5 "2018-06-06T21:06:40Z")

</div>

You’ll automatically get a bounds error if you’re using a negative index:

```julia
julia> x[-2]
ERROR: BoundsError: attempt to access 4-element Array{Float64,1} at index [-2]
Stacktrace:
 [1] getindex(::Array{Float64,1}, ::Int64) at ./array.jl:549

```

Unless you opt out with `@inbounds`, or using something like an offset array where those indices are valid.

So you don’t need to manually test. You can also start julia with `--check-bounds=yes` to ignore `@inbounds` while debugging. That also happens automatically when running tests.

While you’ll probably never intentionally want an index higher than a 64 bit signed integer offers, some strange bug could cause you to shoot that high. Rolling over makes it less likely you’ll notice:

```julia
julia> x = 1:4;

julia> x[typemax(Int)+2]
ERROR: BoundsError: attempt to access 4-element UnitRange{Int64} at index [-9223372036854775807]
Stacktrace:
 [1] throw_boundserror(::UnitRange{Int64}, ::Int64) at ./abstractarray.jl:434
 [2] getindex(::UnitRange{Int64}, ::Int64) at ./range.jl:477

julia> x[typemax(UInt)+2]
1

```

(With the caveat there that typemax(UInt) is twice typemax(Int), so the two cases in the example above aren’t strictly equivalent.)