doc/faq/integers: link to Dan Luu's blog post on checked arithmetic

Also change the text of the final paragraph of this FAQ entry.

Author: StefanKarpinski

doc/manual/faq.rst

@@ -434,17 +434,15 @@ loop iteration, causing different outcomes depending on which iteration the
 failure occurs in. The compiler can unroll the loop, but it cannot
 algebraically reduce multiple operations into fewer equivalent operations.
 
-Saturated integer arithmetic is just one example of a really poor choice of
-language semantics that completely prevents effective performance
-optimization. There are many things that are difficult about C programming,
-but integer overflow is *not* one of them – especially on 64-bit systems. If
-my integers really might get bigger than 2^63-1, I can easily predict that. Am
-I looping over a number of actual things that are stored in the computer? Then
-it's not going to get that big. This is guaranteed, since I don't have that
-much memory. Am I counting things that occur in the real world? Unless they're
-grains of sand or atoms in the universe, 2^63-1 is going to be plenty big. Am
-I computing a factorial? Then sure, they might get that big – I should use a
-``BigInt``. See? Easy to distinguish.
+The most reasonable alternative to having integer arithmetic silently overflow
+is to do checked arithmetic everywhere, raising errors when adds, subtracts,
+and multiplies overflow, producing values that are not value-correct. In this
+[blog post](http://danluu.com/integer-overflow/), Dan Luu analyzes this and
+finds that rather than the trivial cost that this approach should in theory
+have, it ends up having a substantial cost due to compilers (LLVM and GCC)
+not gracefully optimizing around the added overflow checks. If this improves
+in the future, we could consider defaulting to checked integer arithmetic in
+Julia, but for now, we have to live with the possibility of overflow.
 
 
 .. _man-abstract-fields: