Currently, I've implemented add / sub for signals emulating std's primitive types' wrapping_add / wrapping_sub functionality, which I think is the most ergonomic in most cases.
However, there are cases where other behavior is desired - particularly if we want to extract the carry bit on overflow. std provides overflowing_add / overflowing_sub for these purposes, so I think we should:
Expose wrapping_add / wrapping_sub explicitly, and document that add / sub ops alias these
Expose overflowing_add / overflowing_sub which also returns the overflow/carry bit in a tuple
Consider if we should come up with a third option which includes the overflow/carry bit concat'd with the lower bits, as I foresee this is as being useful often
Note that all of this can be emulated today with the current API - a user can concatlow bits to lhs and rhs before add / sub, and they're free to pull apart the resulting Signal however they want.
I still want to handle mul separately; I believe its current behavior is correct/least surprising (but I'm open to feedback on this).
Currently, I've implemented
add/subfor signals emulatingstd's primitive types'wrapping_add/wrapping_subfunctionality, which I think is the most ergonomic in most cases.However, there are cases where other behavior is desired - particularly if we want to extract the carry bit on overflow.
stdprovidesoverflowing_add/overflowing_subfor these purposes, so I think we should:wrapping_add/wrapping_subexplicitly, and document thatadd/subops alias theseoverflowing_add/overflowing_subwhich also returns the overflow/carry bit in a tupleconcat'd with the lower bits, as I foresee this is as being useful oftenNote that all of this can be emulated today with the current API - a user can
concatlowbits tolhsandrhsbeforeadd/sub, and they're free to pull apart the resultingSignalhowever they want.I still want to handle
mulseparately; I believe its current behavior is correct/least surprising (but I'm open to feedback on this).