# Is this expected behavior (0.5 to 0.6 breakage)?
**URL:** https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534
**Category:** General Usage
**Created:** [March 8, 2017, 6:49am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534 "2017-03-08T06:49:18Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@anon94023334](https://discourse.julialang.org/u/anon94023334)
#### Post date: [March 8, 2017, 6:49am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/1 "2017-03-08T06:49:18Z")
In 0.5:
```julia
julia> a = Vector{UInt32}([0x01, 0x02, 0x03])
3-element Array{UInt32,1}:
0x00000001
0x00000002
0x00000003
julia> a + 1
3-element Array{UInt32,1}:
0x00000002
0x00000003
0x00000004
```
In 0.6:
```julia
julia> a = Vector{UInt32}([0x01, 0x02, 0x03])
3-element Array{UInt32,1}:
0x00000001
0x00000002
0x00000003
julia> a + 1
3-element Array{Int64,1}:
2
3
4
```
(Is there a reason this change was made? FWIW, I prefer the old behavior. Changing the type out from under me broke a bunch of things, like `Base.dSFMT.dsfmt_gv_init_by_array`, which expects a `Vector{UInt32}`.
---
### Author:  [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)
#### Post date: [March 8, 2017, 6:53am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/2 "2017-03-08T06:53:50Z")
1 is presumably an Int64, so wouldn’t you prefer the new behaviour, where it promotes to the larger type?
---
### Author:  [@anon94023334](https://discourse.julialang.org/u/anon94023334)
#### Post date: [March 8, 2017, 6:59am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/3 "2017-03-08T06:59:09Z")
I wouldn’t, actually, because the code that was working:
```julia
Base.dSFMT.dsfmt_gv_init_by_array(MersenneTwister(seed).seed+1)
```
breaks in 0.6 because now the argument has switched type, and there’s no method for `dsfmt_gv_init_by_array` that takes a vector of `Int64`.
It seems to me that if you don’t have to change the type, you shouldn’t. (Principle of least surprise?)
---
### Author:  [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)
#### Post date: [March 8, 2017, 7:02am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/4 "2017-03-08T07:02:44Z")
But you are adding two different types, so it has to change the type of one of them. Promoting to the largest type is the most reliable.
Use `one(UInt32)` instead if you want to keep everything a `UInt32`
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [March 8, 2017, 7:05am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/5 "2017-03-08T07:05:50Z")
Julia 0.5 had the behaviour of promotion in vectors being different to outside of vectors.
Below is julia 0.5
```julia
julia> 0x03 + 1
4
julia> [0x03] + 1
1-element Array{UInt8,1}:
0x04
julia> 0x03 + -4
-1
julia> [0x03] + -4
ERROR: InexactError()
in .+(::Array{UInt8,1}, ::Int64) at ./arraymath.jl:82
in +(::Array{UInt8,1}, ::Int64) at ./arraymath.jl:94
```
I would expect that adding a Signed and an Unsigned type would always give a Signed type.
Whether it is inside a Vector or not.
Any code expecting otherwise was already wrong.
Its just that julia 0.5 was wrong in the same way.
* * *
I suggest using `0x1` a `UInt8` literal
Since `0x...` is the literal for a unsigned integer of the smallest type that can hold it.
So it `0x1` will (basically) always promote to the other type when used to increment it.
As compared to `1` which is a signed `Int` literal, which will either be 32bit or 64 bit depending on system.
---
### Author:  [@anon94023334](https://discourse.julialang.org/u/anon94023334)
#### Post date: [March 8, 2017, 7:07am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/6 "2017-03-08T07:07:39Z")
> Promoting to the largest type is the most reliable.
Then I’d suggest that `'a' + 1` should equal `98`, not `'b'`:
```julia
julia> sizeof('a')
4
julia> sizeof(1)
8
```
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [March 8, 2017, 7:12am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/7 "2017-03-08T07:12:00Z")
> [@anon94023334](#):
>
> Then I’d suggest that ‘a’ + 1 should equal 98, not ‘b’:
`Char` is not a numeric type.
Does not follow the:
Promote to largest, and most signed type rule.
Or the Promote to a type that is at least as large and as signed as the most signed input
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [March 8, 2017, 7:39am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/8 "2017-03-08T07:39:22Z")
I don’t think this is an intended change: I cannot find anything in NEWS.md mentioning it. If I remember correctly, array eltypes are (were) not promoted due to the size change in the array. The array of the original example doubles in size due to the promotion, which can be an issue with large arrays.
You should file an issue, if there is non already. At least a NEWS.md entry would be needed if this breaking change was indeed intended.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [March 8, 2017, 8:56am UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/9 "2017-03-08T08:56:32Z")
This was changed in [https://github.com/JuliaLang/julia/pull/19692](https://github.com/JuliaLang/julia/pull/19692) with a corresponding NEWS entry (albeit perhaps a bit cryptic).
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [March 8, 2017, 3:17pm UTC](https://discourse.julialang.org/t/is-this-expected-behavior-0-5-to-0-6-breakage/2534/10 "2017-03-08T15:17:10Z")
x-ref: [https://github.com/JuliaLang/julia/issues/20946](https://github.com/JuliaLang/julia/issues/20946)