3 ms·

> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have

> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?

kaba0 4y ago
https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974
pron 4y ago
Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
- gergo_barany 4y ago
  > E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
  - pron 4y ago
    > 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. Yes and no. As Stroustrup's document says, this is an inevitable result of allowing arithmetic on unsigned integers (i.e. subtracting an unsigned int variable with the value 2 from an unsigned variable with the value 1 has the same effect as explicitly mixing it with a signed integer by adding a -2). The only way to avoid that is to add runtime underflow checks to unsigned arithmetic. Once we have user-defined value types, people can choose to do just that, but there seems to be little point in adding it to the core language; the cost/benefit just isn't there. > overflowing your signed integer is almost certainly wrong as well. True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows.
    - cesarb 4y ago
      > True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows. That's a dangerous argument. The values might be small, until an attacker provides a large one. Your code has to work properly with all possible values, regardless of which ones are more "likely" or "common". In my experience, unsigned makes this simpler, since there are only two cases to consider (zero or positive) instead of four (zero, positive, negative, and INT_MIN); I've expanded on this in a comment here an year ago (https://news.ycombinator.com/item?id=29770689 https://news.ycombinator.com/item?id=29770689).
      - pron 4y ago
        That's one way of looking at it; another is that the common bugs due to underflow with small numbers themselves create more exploitable vulnerabilities. Anyway, I think your point of view is valid, but it will have to become much closer to a consensus before Java considers changing the status quo and adding unsigned types to the core language.
    - gergo_barany 4y ago
      > As Stroustrup's document says, this is an inevitable result of allowing arithmetic on unsigned integers (i.e. subtracting an unsigned int variable with the value 2 from an unsigned variable with the value 1 has the same effect as explicitly mixing it with a signed integer by adding a -2). This is true for C++. It is a meaningless statement in a language where such mixing is not allowed. The semantics of unsigned modular arithmetic can be defined in its own terms, without dragging signed arithmetic and forced implicit conversions into it. The semantics of "subtracting" (unsigned, modularly) 2 from 1 is UINT_MAX. This may or may not be what the user wanted. The semantics of subtracting signed 2 from a signed variable called `arrayIndex` with the value 1 is -1. This is almost certainly not what the user wanted. Why should the language police one case and not the other? It doesn't know the context.
- cesarb 4y ago
  > and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware And with network protocols and file formats, which also often use unsigned types. As an example, one of the many pain points when implementing JGit was the lack of unsigned types (https://marc.info/?l=git&m=124111702609723&w=2 https://marc.info/?l=git&m=124111702609723&w=2). Another heavy user of unsigned types would be cryptographic algorithms, but I expect these to be mostly implemented in other languages (like C, C++, or Rust), with a sprinkling of assembly or SIMD intrinsics in performance-critical loops, and called through JNI.
  - pron 4y ago
    Java does allow you to work with unsigned types efficiently (look at the methods with unsigned in their names in the Integer or Long classes: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Integer.html https://docs.oracle.com/en/java/javase/19/docs/api/java.base...). But those uses are relatively specialised and the vast majority of Java users don't need that. So it's best to keep them as APIs rather than in the core language.

kaba0 4y ago

https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974

pron 4y ago

Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...

gergo_barany 4y ago
> E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
- pron 4y ago
  > 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. Yes and no. As Stroustrup's document says, this is an inevitable result of allowing arithmetic on unsigned integers (i.e. subtracting an unsigned int variable with the value 2 from an unsigned variable with the value 1 has the same effect as explicitly mixing it with a signed integer by adding a -2). The only way to avoid that is to add runtime underflow checks to unsigned arithmetic. Once we have user-defined value types, people can choose to do just that, but there seems to be little point in adding it to the core language; the cost/benefit just isn't there. > overflowing your signed integer is almost certainly wrong as well. True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows.
  - cesarb 4y ago
    > True yet less likely because most integer values appearing in programs are small, and so underflows are more common than overflows. That's a dangerous argument. The values might be small, until an attacker provides a large one. Your code has to work properly with all possible values, regardless of which ones are more "likely" or "common". In my experience, unsigned makes this simpler, since there are only two cases to consider (zero or positive) instead of four (zero, positive, negative, and INT_MIN); I've expanded on this in a comment here an year ago (https://news.ycombinator.com/item?id=29770689 https://news.ycombinator.com/item?id=29770689).
    - pron 4y ago
      That's one way of looking at it; another is that the common bugs due to underflow with small numbers themselves create more exploitable vulnerabilities. Anyway, I think your point of view is valid, but it will have to become much closer to a consensus before Java considers changing the status quo and adding unsigned types to the core language.
  - gergo_barany 4y ago
    > As Stroustrup's document says, this is an inevitable result of allowing arithmetic on unsigned integers (i.e. subtracting an unsigned int variable with the value 2 from an unsigned variable with the value 1 has the same effect as explicitly mixing it with a signed integer by adding a -2). This is true for C++. It is a meaningless statement in a language where such mixing is not allowed. The semantics of unsigned modular arithmetic can be defined in its own terms, without dragging signed arithmetic and forced implicit conversions into it. The semantics of "subtracting" (unsigned, modularly) 2 from 1 is UINT_MAX. This may or may not be what the user wanted. The semantics of subtracting signed 2 from a signed variable called `arrayIndex` with the value 1 is -1. This is almost certainly not what the user wanted. Why should the language police one case and not the other? It doesn't know the context.
cesarb 4y ago
> and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware And with network protocols and file formats, which also often use unsigned types. As an example, one of the many pain points when implementing JGit was the lack of unsigned types (https://marc.info/?l=git&m=124111702609723&w=2 https://marc.info/?l=git&m=124111702609723&w=2). Another heavy user of unsigned types would be cryptographic algorithms, but I expect these to be mostly implemented in other languages (like C, C++, or Rust), with a sprinkling of assembly or SIMD intrinsics in performance-critical loops, and called through JNI.
- pron 4y ago
  Java does allow you to work with unsigned types efficiently (look at the methods with unsigned in their names in the Integer or Long classes: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/Integer.html https://docs.oracle.com/en/java/javase/19/docs/api/java.base...). But those uses are relatively specialised and the vast majority of Java users don't need that. So it's best to keep them as APIs rather than in the core language.