Open Radar

 
Summary:
Swift overflow "protection" that cannot be caught and causes crashes  is the wrong default, please change it to something safer, particularly as Swift is supposed to be safe language.

See also my article:  http://blog.metaobject.com/2014/06/how-to-swiftly-destroy-370-million.html 

Alternatives are:

1.  A proper object-oriented numeric tower, like Smalltalk's

Such a numeric tower automatically overflows to bigints and/or floats or fractions as necessary.  The use of tagged (small-)integers almost completely eliminates overhead, especially on 64 bit machines and current hardware that tends to be memory-bound.  Safer and more capable.

2.  Wraparound

The existing behavior.  While not ideal, it seems preferable to dumping core.  Dumping core could be preserved as an opt-in debugging feature.  (In a sense it already is, as it is the behavior of -Ofast, and -Ofast is necessary for remotely adequate performance).

3.   Clamping

Arguably the correct behavior for explicitly size/range restricted values.  The programmer specifically said she didn't want a value out of this range, and the closest value to the one requested is the clamped value ( so MAX(type) for overflow, MIN(type) for underflow).

The ideal solution would probably be a combination of (1), unrestricted overflow with either (2) or (3), (2) for closeness to the underlying hardware (3) for closeness to the intended semantics of limited precision integers.

Steps to Reproduce:
var a = 2
var b:Int16
for i in 1..100 {
  a=a*2
  println(a)
  b=Int16(a)
}


Expected Results:
Correct result, clamped result, wraparound (machine arithmetic) result, in that order of preference.