Integer and Decimal Type Renames for 2.0

[younies]

Discussion: core decimal types

• @sffc Did we want pub type UnsignedDecimal = WithDecimal<UnsignedInteger>? Decimal is an Integer with an extra field that specifies the location of the decimal point.
• @robertbastian Yes, but it is extra work.
• @sffc Is it breaking to change pub struct UnsignedDecimal to pub type UnsignedDecimal?
• @robertbastian Maybe, not sure
• @sffc If we keep fixed_decimal as a separate non-stable crate, this is fine, because the only thing we format is Decimal
• @sffc Do we want the type wrap to be private? pub struct Decimal(Signed<UnsignedDecimal>)
• @robertbastian That requires duplicating all the functions or derefing, and removing a deref step seems more semver breaking than the alternative

Proposal:

1. Definitely in 2.0:
   • pub type Decimal = Signed<UnsignedDecimal>
   • pub struct UnsignedDecimal
2. Additional integer renames (see point 3):
   • pub type Integer = Signed<UnsignedInteger>
   • pub struct UnsignedInteger
3. If fixed_decimal remains a util crate, we can do the integer changes post-2.0, which may involve a range dependency from icu_decimal to fixed_decimal. If we merge it into icu_decimal, we put the integer types behing an experimental feature.
4. If we can make pub type UnsignedDecimal in 2.x, great, if not, fine, maybe in 3.0

LGTM: @sffc @younies @robertbastian @echeran

[Manishearth]

1. Definitely in 2.0:

   • pub type Decimal = Signed<UnsignedDecimal>
   • pub struct UnsignedDecimal

This happened

2. Additional integer renames (see point 3):

   • pub type Integer = Signed<UnsignedInteger>
   • pub struct UnsignedInteger

This didn't. We have FixedInteger. This is not reexported and can be maybe fixed with a range dep.

4. If we can make pub type UnsignedDecimal in 2.x, great, if not, fine, maybe in 3.0

This is done.

[Manishearth]

Moving this to 3.0 for FixedInteger. If someone wishes to do this earlier in a semver compat way they are welcome to try.

[robertbastian]

A weakness of this model is that UnsignedDecimal is not Copy, so we usually want to pass it by reference. This means we sometimes have Signed<&UnsignedDecimal> with no way to convert to &Signed<UnsignedDecimal> without cloning.

[sffc]

I've been thinking about this.

I think: the "core" type chosen should largely be based on the input. So:

• u64 gets UnsignedInteger
• i64 gets Integer = WithSign<UnsignedInteger>
• String decimal gets Decimal = WithFraction<Integer>
• f64 gets FullDecimal = WithNaN<WithInfinity<Decimal>>

Then when you add compact decimal support, you wrap the whole thing.

Still not sure whether WithSign should go inside or outside of WithFraction, but I think this is a convincing argument that WithSign should go inside of WithCompact.

There's a good argument to be made that the decimal formatters should take these by value rather than by reference.