*shuts laptop forever*pic.twitter.com/3GS1JfNDSP
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
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.
The example is just as interesting without the conversions at assignment.
The C example is not very strange or bizarre - it is a result of sign extension. https://en.wikipedia.org/wiki/Sign_extension …
I think new languages should make promises that == is always false if the values are not actually equal (no lossy implicit conversions).
Signed/unsigned comparison errors would rule this out. (i.e: enable -Werror=sign-compare and every warning flag you can get your hands on)
Wouldn't rule out the floating point version though.
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.
This is why JSLint and other tools prefer ===
The "===" still does stupid thing with matching types: >>> a === b false
Like change the language spec?
I'm beginning to think == is just a bad operator to have in a language. Even if you have super-strict typing, you have to work with floating point, arbitrary precision timestamps, mutable objects, dynamic streams, nulls, etc, etc...
The only safe non-stupid thing would be to always return false. This is not very useful. => Better yet, disallow == on mismatched types to start with.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.