Now that we've started adding signed ops (eg. mul_signed) it's natural to allow specifying signed Constant literals in addition to unsigned bit patterns. Note that signed literals would still need to be range-checked.
This would still represent these Signals in the same unsigned way internally (as there's currently no concept of signed-ness in the graph API today, see #7 for potential future improvements in this area), but it be much more convenient when specifying signed literals. Further, in the absence of additional type constraints, rust will infer numeric constants to be of signed types (eg. i32), so today calling eg. lit(1, 1) on a Module will actually raise an error even though 1 would have fit as an unsigned type, so it needs to be annotated eg 1u32 to specify an unsigned literal explicitly. This case would be naturally resolved if we allowed signed types.
Now that we've started adding signed ops (eg.
mul_signed) it's natural to allow specifying signedConstantliterals in addition to unsigned bit patterns. Note that signed literals would still need to be range-checked.This would still represent these
Signals in the same unsigned way internally (as there's currently no concept of signed-ness in thegraphAPI today, see #7 for potential future improvements in this area), but it be much more convenient when specifying signed literals. Further, in the absence of additional type constraints, rust will infer numeric constants to be of signed types (eg.i32), so today calling eg.lit(1, 1)on aModulewill actually raise an error even though1would have fit as an unsigned type, so it needs to be annotated eg1u32to specify an unsigned literal explicitly. This case would be naturally resolved if we allowed signed types.