In use cases when we need to model discount percentage for price adjustments, it's preferable to avoid doubles and use decimal type.
We already have a standard "Money" type consisting of "int64 units" and "int32 nanos" and "currency code".
It will be convenient to have another standard DecimalAmount type as well for use cases when we need money-related fields (like percentage) but without currency_code.
It can look like this:
message DecimalAmount {
// The whole units of the amount.
int64 units = 2;
// Number of nano (10^-9) units of the amount.
// The value must be between -999,999,999 and +999,999,999 inclusive.
// If units is positive, nanos must be positive or zero.
// If units is zero, nanos can be positive, zero, or negative.
// If units is negative, nanos must be negative or zero.
int32 nanos = 3;
}
In use cases when we need to model discount percentage for price adjustments, it's preferable to avoid doubles and use decimal type. We already have a standard "Money" type consisting of "int64 units" and "int32 nanos" and "currency code". It will be convenient to have another standard DecimalAmount type as well for use cases when we need money-related fields (like percentage) but without currency_code.
It can look like this:
message DecimalAmount { // The whole units of the amount. int64 units = 2;
// Number of nano (10^-9) units of the amount. // The value must be between -999,999,999 and +999,999,999 inclusive. // If
units
is positive,nanos
must be positive or zero. // Ifunits
is zero,nanos
can be positive, zero, or negative. // Ifunits
is negative,nanos
must be negative or zero. int32 nanos = 3; }