[thaumasiotes]

> Wouldn’t that last example be incorrect mathematically? For example, if the Int8 was -10 and the UInt16 was 10, what would that casting do?

Well....

Signed integer arithmetic and unsigned integer arithmetic do not differ. At all.

The difference between an Int16 and a UInt16 is not in the 16 defined bits. It's in the infinite number of implicit bits representing place values above 2^15. Those bits are always 0 for the UInt16, but they're identical with the high bit of the Int16.

So it's not clear what it would mean for the result type to be "incorrect mathematically". Mathematically, an Int16 and a UInt16 are the same thing.

However, the path by which you promote the values does matter. I don't know what Julia does. But:

      -10   (Int8) +   10 (UInt16)
      -10  (Int16) +   10 (UInt16)
    65526 (UInt16) +   10 (UInt16)
        0 (UInt16)

is a different result from

      -10   (Int8) +   10 (UInt16)
      246  (UInt8) +   10 (UInt16)
      246 (UInt16) +   10 (UInt16)
      256 (UInt16)

One of those should be the result Julia gives. I tend to hope it's the first one. That would correspond to a promotion strategy of "always expand the type to its full width before converting between signed and unsigned". Expansion (and shift, I guess) is the only operation for which the difference between signed and unsigned is relevant.

> Would a better promotion be Int32 for both?

Probably not; that would imply that when you add two UInt16s together, you expect to get a UInt32 (or UInt17...) back.

[HalcyonCowboy]

It took me a couple of readings to make sure I understood what you were saying, thanks for the reply. I think my misunderstanding was from not knowing Julia and thinking about promotion of values as having a permanent effect on the variables used, which isn’t what’s happening. As well, it requires the user to understand what they’re doing when they’re using an operator that uses automatic promotion, and to think about what they want to happen. For example, if Int8 = -10 and UInt16 = 5, and I’m expecting an answer of -5, then I’ll need to be more explicit to get the number I’m looking for. If I’m expecting 65530, then the implicit promotion works fine. Of course, this is no different from any other programming language that allows addition of differing types.

Great point on the path dependence.

[thaumasiotes]

> For example, if Int8 = -10 and UInt16 = 5, and I’m expecting an answer of -5, then I’ll need to be more explicit to get the number I’m looking for. If I’m expecting [65531], then the implicit promotion works fine.

That depends on what you're hoping to do with the number you're looking for. If you wanted -5 as an Int16, the bit pattern would be 1111 1111 1111 1011 or 0xFFFB.

If you wanted 65531 as a UInt16, the bit pattern for that is 1111 1111 1111 1011 or 0xFFFB. You're getting the same result either way. And any values you compute from that result [that is, by arithmetic] are going to be unaffected by whether you labeled the result "Int16" or "UInt16", because that's just a label. If you labeled 0xFFFB a "Snerf", the arithmetic would still be the same.

There are only a very restricted set of places where you need to be explicit about whether you think of your variable as an Int or a UInt:

1. When you're widening it.

2. When you're doing a right shift.

3. When you're formatting it for display to a human.

[HalcyonCowboy]

Yeah, case three was the one I was thinking of, though cases one and two are interesting as well. Number two requires you to think about using an arithmetic or logical right shift, though I'm struggling to think of a situation where you'd be promoting types and then not know what your intent was if you're then doing a right shift. I guess my confusion here is simply related to the idea that if you're getting that deep into binary, you'd probably want to be more explicit about what types you want to promote to, rather than relying on the Julia defaults. It's been a while since I've needed to think deeply about bitwise operations, still just as interesting as I remember.