4 ms·

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.
  • Vendan 8y ago
    no, I get that, but int is not for pointer<->integer conversions. That is very specifically a separate type: uintptr an unsigned integer large enough to store the uninterpreted bits of a pointer value https://golang.org/ref/spec#Numeric_types https://golang.org/ref/spec#Numeric_types
    • scott_s 8y ago
      Sure, but did I imply it was? I’m genuinely confused.
      • Vendan 8y ago
        > language allows casting pointers to integers The original thread was about converting int to be an arbitrary precision type: "so that 'int' can become a true integer". One would imagine that, to preserve the ability to do pointer <-> non-pointer number, they would just leave uintptr alone, and so basically ignore your concerns, whereas int as the "native type" for slice indexes and the like is a more likely reason to prevent messing with "int" itself
        • scott_s 8y ago
          Okay, that's the source of the confusion. I was not replying to that sentiment, which is a nuanced discussion on what an int should be. I was replying to the_clarence's categorical dismissal of variable width integer types.