# Auto singly promotion for bittypes upon overflow?

**URL:** <https://discourse.julialang.org/t/auto-singly-promotion-for-bittypes-upon-overflow/6255>\
**Category:** Internals & Design\
**Tags:** proposal\
**Created:** [October 5, 2017, 3:36am UTC](https://discourse.julialang.org/t/auto-singly-promotion-for-bittypes-upon-overflow/6255 "2017-10-05T03:36:31Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [October 5, 2017, 3:36am UTC](https://discourse.julialang.org/t/auto-singly-promotion-for-bittypes-upon-overflow/6255/1 "2017-10-05T03:36:32Z")

</div>

```julia
function overflow()
  a = 2^63
  return a
end
overflow()

function overflow_no()
  a = BigInt(2)^63
  return a
end
overflow_no()

```

In the above example overflow() will overflow with no warning, but overflow\_no() works fine. This is a very subtle “bug” that data scientists coming from a pure statistics/machine learning background may not fully appreciate and can cause lots of headaches in debugging.

Wouldn’t it make sense for Julia to have a way to define an auto-promotion rule for bit types when it overflows? E.g. auto promote the Int64 to BigInt when it overflows. This feels more natural to me, a mathematician/statistician by training.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [October 5, 2017, 6:44am UTC](https://discourse.julialang.org/t/auto-singly-promotion-for-bittypes-upon-overflow/6255/2 "2017-10-05T06:44:26Z")

</div>

Unfortunately, that’s not possible without a large performance hit. See [the FAQ](https://docs.julialang.org/en/stable/manual/faq/#Why-does-Julia-use-native-machine-integer-arithmetic?-1). For scientific work, in general better use `Float64` than `Int`, since it progressively loses absolute precision when moving away from zero, and becomes `Inf` in case of overflow. `Int` should be reserved for purely integer values, e.g. an index into an array (which cannot overflow because of memory use limits).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 6, 2017, 11:36am UTC](https://discourse.julialang.org/t/auto-singly-promotion-for-bittypes-upon-overflow/6255/3 "2017-10-06T11:36:51Z")

</div>

Overflow used to be a big issue on say 16-bit CPUs (or for 8-bit integers…).

This is of course increasingly rare and very much so for Int64. So rare in fact that a better option may be to just fail with an OverflowException.

[For indexes into arrays Int (Int64 or Int32) will never overflow, as arrays can’t get that big.]

Note also there is Int128 datatype (faster than BigInt), with overflow even more rare, but possible.

All of the Integer types can trivially be wrapped into a new type that check for overflow (already done in a package?), and then throw an exception (with a performance hit, see other post). In theory, such a type could also be made the default replacing the current Integer types (with the same performance cost, doubt the compiler could reduce it; it really wouldn’t have more information to do so) so that you need no syntax changes [for literal values].

That new default would not be accepted for Julia, unless it’s a runtime command-line option,. Such an option would only work if you’ve not defined a new type.

There are some issues on this, I found just this one again (note marked “1.x”-milestone, desiding on this isn’t important for 1.0 as the above plan breaks no code):

[https://github.com/JuliaLang/julia/issues/855](https://github.com/JuliaLang/julia/issues/855)