6 ms·

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

drb91 8y ago
People have traditionally wanted to use the maximum sized type that can fit in a register.
- user5994461 8y ago
  Traditionally the register size was too small, it's very common to have numbers above 256 or 65536. It's not true anymore with 32 bits numbers and a limit of 2 billion.
- Someone 8y ago
  More precisely: they wanted the integer type that was large enough and ran their code fastest. On CPUs with 64-bit and 32-bit registers, that typically is the register-sized integer type. Machines with 16-bit registers are a bit of an edge case, as 16-bit integers may both be a lot faster on them then 32-bit integers and, in many cases, too small) If go chose to use 32-bit integers as default, some users on 64-bit systems would complain that they couldn’t create, say, an array of 6 billion ints. If they chose 64-bit, some users on 32-bit systems would complain their loops were needlessly slow, and code bloated (why waste 4 bytes of almost every integer in a program?) Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag) A sufficiently advanced compiler would help here, but go doesn’t have one (not exceptional), and doesn’t even aim to have one (compilation speed seems more of a goal than run-time speed)
  - TheDong 8y ago
    > Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag) Isn't it already the case that you can switch between int sizes with compiler flags? var i int That will be 32 bits if I compile it with GOOS=linux GOARCH=386 and will be 32 bits if I swap in amd64 instead of 386 there. Is there any language where generics are useful for switching between int sizes? None come to mind offhand, so I don't quite understand what you mean.
adrianmonk 8y ago
It's a perfectly reasonable niche use case for achieving maximum performance. My main issues with it are: 1. Like many other performance optimizations, it is a trade-off. You may be sacrificing easy maintenance or even introducing breakage (if the person using it doesn't understand the limitations and implications). So IMHO you should only do it if you can show through profiling, etc. that the gain is real and worth it. 2. As a matter of language ergonomics, it should never be something that anyone does unknowingly. You should have to explicitly ask for it. The type name should be something blindingly obviously like "native_int" or "word_int".
- dcow 8y ago
  Even Swift who’s mantra is do nothing unexpected or implicit has a machine dependent (word sized) Int type.
  - the_clarence 8y ago
    That’s insane
- the_clarence 8y ago
  You’re trading off security here. Users are going to shoot themselves in the foot assuming that int is this size or this size.
throwaway34241 8y ago
On 64 bit systems you can have large arrays that are bigger than a 32 bit int. For example, it's nice to be able to load a >2GB file into a byte array. For comparison, Java's int type is 32 bits on 64 bit systems, but then this limits the array size. It seems like a lesser evil to have a platform-native int type than to limit the size of arrays (especially since servers can be expected to increase their max memory going forward). Of course, standardizing on 64 bit ints instead would require emulating them on 32 bit systems, when they can't support that much memory anyway (you could argue that 32 bit systems don't matter much anymore, but if you really don't care about ever running on them, then you can just treat 'int' as 64 bits and not variable size).
- Too 8y ago
  C# is the same, int is merely an alias for Int32 and the default Array type only holds 32bit. If you really need to, it's easy to wrap this into your own BigArray-class holding a 32bit-array-of-32bit-arrays and overriding the []-operator with Int64 as argument.
scott_s 8y ago
It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.
- Vendan 8y ago
  I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing
  - friday99 8y ago
    Except length/cap/index are always positive, so I think int was a mistake here.
    - joppy 8y ago
      I think that the rationale for using int for array indices and lengths and so on is to avoid shooting yourself in the foot with wrap-around arithmetic (again, my thesis being that when 99% of people use integers, they expect them to behave like integers and not wrap) Take for example code which finds consecutive differences in a list, something like for i := 0; i < len(list) - 1; i++ { print(list[i+1] - list[i]) } This code looks fine and reasonable, and we even avoided the off-by-one error at the end. However, if len(list) is a uint and we run this on an empty list, len(list) - 1 is then 2^32 or something, and the program explodes. So this is the rationale for using signed integers rather than unsigned integers. I think the language semantics should go further, and use true integers pretty much everywhere. Note that the compiler could still easily see that the index variable in the loop above is bounded, and use a machine word under-the-hood. But the programmer only ever has to think about well-behaved integers.
  - scott_s 8y ago
    I actually agree. I was responding to someone who dismissed the entire concept.

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

drb91 8y ago

People have traditionally wanted to use the maximum sized type that can fit in a register.

user5994461 8y ago
Traditionally the register size was too small, it's very common to have numbers above 256 or 65536. It's not true anymore with 32 bits numbers and a limit of 2 billion.
Someone 8y ago
More precisely: they wanted the integer type that was large enough and ran their code fastest. On CPUs with 64-bit and 32-bit registers, that typically is the register-sized integer type. Machines with 16-bit registers are a bit of an edge case, as 16-bit integers may both be a lot faster on them then 32-bit integers and, in many cases, too small) If go chose to use 32-bit integers as default, some users on 64-bit systems would complain that they couldn’t create, say, an array of 6 billion ints. If they chose 64-bit, some users on 32-bit systems would complain their loops were needlessly slow, and code bloated (why waste 4 bytes of almost every integer in a program?) Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag) A sufficiently advanced compiler would help here, but go doesn’t have one (not exceptional), and doesn’t even aim to have one (compilation speed seems more of a goal than run-time speed)
- TheDong 8y ago
  > Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag) Isn't it already the case that you can switch between int sizes with compiler flags? var i int That will be 32 bits if I compile it with GOOS=linux GOARCH=386 and will be 32 bits if I swap in amd64 instead of 386 there. Is there any language where generics are useful for switching between int sizes? None come to mind offhand, so I don't quite understand what you mean.

adrianmonk 8y ago

It's a perfectly reasonable niche use case for achieving maximum performance. My main issues with it are: 1. Like many other performance optimizations, it is a trade-off. You may be sacrificing easy maintenance or even introducing breakage (if the person using it doesn't understand the limitations and implications). So IMHO you should only do it if you can show through profiling, etc. that the gain is real and worth it. 2. As a matter of language ergonomics, it should never be something that anyone does unknowingly. You should have to explicitly ask for it. The type name should be something blindingly obviously like "native_int" or "word_int".

dcow 8y ago
Even Swift who’s mantra is do nothing unexpected or implicit has a machine dependent (word sized) Int type.
- the_clarence 8y ago
  That’s insane
the_clarence 8y ago
You’re trading off security here. Users are going to shoot themselves in the foot assuming that int is this size or this size.

throwaway34241 8y ago

On 64 bit systems you can have large arrays that are bigger than a 32 bit int. For example, it's nice to be able to load a >2GB file into a byte array. For comparison, Java's int type is 32 bits on 64 bit systems, but then this limits the array size. It seems like a lesser evil to have a platform-native int type than to limit the size of arrays (especially since servers can be expected to increase their max memory going forward). Of course, standardizing on 64 bit ints instead would require emulating them on 32 bit systems, when they can't support that much memory anyway (you could argue that 32 bit systems don't matter much anymore, but if you really don't care about ever running on them, then you can just treat 'int' as 64 bits and not variable size).

Too 8y ago
C# is the same, int is merely an alias for Int32 and the default Array type only holds 32bit. If you really need to, it's easy to wrap this into your own BigArray-class holding a 32bit-array-of-32bit-arrays and overriding the []-operator with Int64 as argument.

scott_s 8y ago

It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.

Vendan 8y ago
I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing
- friday99 8y ago
  Except length/cap/index are always positive, so I think int was a mistake here.
  - joppy 8y ago
    I think that the rationale for using int for array indices and lengths and so on is to avoid shooting yourself in the foot with wrap-around arithmetic (again, my thesis being that when 99% of people use integers, they expect them to behave like integers and not wrap) Take for example code which finds consecutive differences in a list, something like for i := 0; i < len(list) - 1; i++ { print(list[i+1] - list[i]) } This code looks fine and reasonable, and we even avoided the off-by-one error at the end. However, if len(list) is a uint and we run this on an empty list, len(list) - 1 is then 2^32 or something, and the program explodes. So this is the rationale for using signed integers rather than unsigned integers. I think the language semantics should go further, and use true integers pretty much everywhere. Note that the compiler could still easily see that the index variable in the loop above is bounded, and use a machine word under-the-hood. But the programmer only ever has to think about well-behaved integers.
- scott_s 8y ago
  I actually agree. I was responding to someone who dismissed the entire concept.