If you accept that an Int8 is a narrower integer type than Int32|64 and
that the two Int8 operands to an "addition, subtraction, multiplication,"
are promoted to Ints before the operation occurs "To minimize the
practical impact of this overflow," It is hard to argue that they have
first been promoted to a common type (common in the sense of 'shared'; they
are both of this shared type -- in this example, they were of a narrower
shared type before the promotion. If you read 'common' to mean a type that
each operand reaches traversing its own supertype hierarchy, being promoted
to a type that is a joint supertype; that is a very high bar for a language
that is not at present offering inheritance of instantiable types.
Following your sense that somewhere was a contradiction
"In applications where overflow is possible, explicit checking for
wraparound produced by overflow is essential; ... To minimize the practical
impact of this overflow, integer addition, subtraction, multiplication, and
exponentiation operands are promoted to Int or UInt from narrower integer
types. (However, divisions, remainders, and bitwise operations do not
promote narrower types.)."
after reading that, I did not expect this:
```julia
```
On Monday, August 3, 2015 at 7:42:03 PM UTC-4, Sisyphuss wrote:
>
> "integer addition... operands are promoted to Int or UInt from narrower
> integer types" (
> http://docs.julialang.org/en/latest/manual/integers-and-floating-point-numbers/
> )
>
> "These catch-all rules first promote all operands to a common type " (
> http://docs.julialang.org/en/latest/manual/conversion-and-promotion/#man-conversion-and-promotion
> )
>
> `Int8` is definitely not a subclass of `Int`, do this two assertions
> contradict to each other?
>
