For fun, a C version: uint64_t a = -1; uint32_t b = -1; int c = -1; a==c; // true b==c; // true a==b; // false
-
-
Any good compiler should reject assigning a negative integer to an unsigned integer without an explicit cast.
2 replies 0 retweets 2 likes -
The example is just as interesting without the conversions at assignment.
1 reply 0 retweets 0 likes -
The C example is not very strange or bizarre - it is a result of sign extension. https://en.wikipedia.org/wiki/Sign_extension …
1 reply 0 retweets 4 likes -
I think new languages should make promises that == is always false if the values are not actually equal (no lossy implicit conversions).
1 reply 0 retweets 3 likes -
Replying to @RichFelker @cyanbeanie and
Signed/unsigned comparison errors would rule this out. (i.e: enable -Werror=sign-compare and every warning flag you can get your hands on)
1 reply 0 retweets 3 likes -
Replying to @EyalL @cyanbeanie and
Wouldn't rule out the floating point version though.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @EyalL and
And would be painful to use. The right solution for new languages moving forward is defining == in terms of actual value equality, even when the types make it require more code to implement the comparison.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @cyanbeanie and
cost model suffers, for such a low level language. explicit expensiveness may be better.
1 reply 0 retweets 0 likes -
Replying to @EyalL @cyanbeanie and
When the cost matters you can always use matching types, either for the underlying operands in the expressions or both sides or by casting one or both sides.
2 replies 0 retweets 0 likes
(1<<28)+1==0x1p28f is misleading. (float)((1<<28)+1)==0x1p28f is obviously reasonable.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.