IMO, rand should be able to accept any sort on Integer, and in this case unsigned is actually the only logical value, so I would call this a bug.

julia> rand(Base.Random.GLOBAL_RNG, 0:10, UInt64(4))
ERROR: MethodError: no method matching rand(::MersenneTwister, ::UnitRange{Int64}, ::UInt64)
Closest candidates are:
rand(::AbstractRNG, !Matched::Integer…) at random.jl:369
rand(::AbstractRNG, !Matched::Type, ::Integer, !Matched::Integer…) at random.jl:372
rand(::AbstractRNG, ::UnitRange{#s267 } where #s267<:Union{BigInt, Bool, Signed, Unsigned}) at random.jl:654
…
Stacktrace:
[1] macro expansion at ./REPL.jl:97 [inlined]
[2] (::Base.REPL.##1 #2{Base.REPL.REPLBackend})() at ./event.jl:73

Try

```
rand(Base.Random.GLOBAL_RNG, 0:10, 4)
```

Even though indexes are “logically” unsigned for plain vanilla arrays, the convention in Julia is to use `Int`

. This prevents unpleasant surprises when doing arithmetic (eg consider subtraction which would result in a negative value, etc).

Slightly related, see the discussion there:

I would have thought that the fill() function is smarter. Now I have to cast to the widest type before calling it… Any thoughts? Am I too picky?
julia> fill(0, (Int64(10), Int32(8)))
ERROR: MethodError: no method matching fill(::Int64, ::Tuple{Int64,Int32})
Closest candidates are:
fill(::Any, ::Tuple{Vararg{Int64,N}} where N) at array.jl:253
fill(::Any, ::Integer...) at array.jl:254
julia> fill(0, (Int64(10), Int64(8)))
10×8 Array{Int64,2}:
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0…

It’s “fixed” on master, no idea when exactly!