Not really, since the argument seems to be that unsigned integer types should be used widely for indexes and offsets into arrays, rather than just for bit patterns.
The argument against using unsigned integers for anything arithmetic, including indexes and sizes is the following. If all your code is perfect, sure, you will always get a valid positive index, so unsigned integers should be fine. It's not uncommon, however, to make arithmetic errors, such as computing `a - b` when you meant to computing `b - a`. With signed integers, when you make such an error, you can tell if you erred on the side of computing something too small or too large. It's a small but useful bit of information. Moreover, there are cases where unsigned integers don't allow you to catch such errors at all, while mistakes are obvious with signed integers: e.g. negative timeouts vs very large positive timeouts; similarly for stream offsets or indexes into sufficiently large arrays. So Julia's philosophy for whether to use signed or unsigned integers is this: - For arithmetic, including indexes and sizes, you should use signed integer types of sufficient size – usually your system's Int type. For arithmetic, numeric value is what's important, so all signed integers are printed in decimal and storage size is not indicated. When you enter a decimal integer literal, you get a signed value of sufficiently large signed integer type. - If you are working with bit patterns rather than arithmetic values, use unsigned integers. Since the number of bits is important here, unsigned integers are printed in hex. Likewise, when you enter a hex integer literal, you get an unsigned integer value of size indicated by the number of digits used. On Sun, Sep 20, 2015 at 5:04 PM, Jesse Johnson <[email protected]> wrote: > > > On 09/20/2015 04:11 PM, Milan Bouchet-Valat wrote: > > > > The point is, in Julia using unsigned ints to store values that should > > always be positive is *not* recommended. > > This is starting to get off my main topic of consistently printing > numerical types and allowing the user to change the default print > formats, but you bring up an interesting point I'd like to discuss in a > separate thread. >
