The number of bytes read and unsigned numbers

As an example to clarify my question, in Google Go 1.0, the following interface is defined in the "io" package:

type Reader interface {
    Read(p []byte) (n int, err error)
}

Especially the result parameter list (n int, err error) intrigues me. Intrinsically the number of bytes can not be negative, according to the documentation of the interface:

> It returns the number of bytes read (0 <= n <= len(p))[...]

In C the reason to use int was the in-band value -1 to signal an error condition (see Effective Go: Multiple return values). Because of multiple return values, special in-band values are not necessary.

There exists the type uint in Go 1.0.

What is the specific reason for using int versus uint in the case of values that only use the positive range [0,∞) without the need for having special in-band values?

The de facto numeric type for integers is int. This is partly because signed int overflow in a more obvious way.
A small overflow of an uint ends up looking like a valid value, but a small overflow of a signed int will be negative and panic in places expecting a positive integer, eg. slicing.

This is important because you'll commonly take the 'n' from Read() and slice 'p' to that length.

eg.

n, err := a.Read(p)
p = p[:n]
processReadData(p)

The de facto numeric type for integers in most cases is int. For example, len(x) and cap(x) return int values even though those too cannot be negative. In most cases returning an int helps avoid type conversions between different numeric types.

So yes, Read() could have returned a uint, but this would make it slightly more unwieldy to work with.