Change:
impl i8 { int_impl! { i8, i8, u8, 8, 7, -128, 127, 2, "-0x7e", "0xa", "0x12", "0x12", "0x48", "[0x12]", "[0x12]", "", "" } <del> widening_impl! { i8, i16, 8, signed } </del> } #[lang = "i16"] impl i16 { int_impl! { i16, i16, u16, 16, 15, -32768, 32767, 4, "-0x5ffd", "0x3a", "0x1234", "0x3412", "0x2c48", "[0x34, 0x12]", "[0x12, 0x34]", "", "" } <del> widening_impl! { i16, i32, 16, signed } </del> } #[lang = "i32"]

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.