[API Proposal]: Scale property for the decimal datatype

[vanillajonathan]

Background and motivation

To quickly and easily get the number of decimal places of a decimal. Like SqlDecimal.

API Proposal

namespace System
{
    public struct Decimal // : ...
    {
+        // Gets the number of decimal places.
+        public byte Scale { get; }
    }
}

API Usage

decimal foo = 1.234m;
Console.WriteLine(foo.Scale); // 3

Alternative Designs

No response

Risks

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

To quickly and easily get the different parts (the whole number and the fractional part) of a decimal. Also allows to determine the length of the different parts.

API Proposal

namespace System
{
    public struct Decimal // : ...
    {
+        public int WholeNumber => //  The whole number part (before the decimal separator)
+        public int FractionalPart => // The decimal part (after the decimal separator)
    }
}

API Usage

decimal foo = 12.34m;
Console.WriteLine(foo.WholeNumber); // 12
Console.WriteLine(foo.FractionalPart); // 34

decimal foo = 1.2345m;
Console.WriteLine(foo.WholeNumber.ToString().Length); // 1
Console.WriteLine(foo.FractionalPart.ToString().Length); // 4

Alternative Designs

No response

Risks

No response

Author:	vanillajonathan
Assignees:	-
Labels:	api-suggestion, area-System.Runtime, untriaged
Milestone:	-

[svick]

1. I think that this version of FractionalPart wouldn't be useful, because of leading zeroes: e.g. how would you differentiate between 1.5m and 1.05m, since presumably, both would return 5.
2. You can already get the whole number part by casting to int. Keep in mind that the range of decimal is much larger than that of int, so this may throw. And this then also gives you a fairly simple way of getting the fractional part (as decimal): x - (int)x.
3. Why do you think that getting the lengths of the two parts is something that should be easy? Is there some class of programs where this is a common operation?

[tannergooding]

The signature as given wouldn't work/be useful, IMO.

There are cases where breaking it into (decimal IntegerPart, decimal FractionalPart) may be useful. This is used internally in the BCL and exposed by other languages as modf (or similar, based on the C/C++ name generally).

However, there are also limitations with how decimal can be used and what values it can represent and so it may not be as useful as it would be on some IEEE 754 decimal like type or the IEEE 754 binary types (float, double, half, etc)

[vanillajonathan]

@svick

• I think that this version of FractionalPart wouldn't be useful, because of leading zeroes: e.g. how would you differentiate between 1.5m and 1.05m, since presumably, both would return 5.

• You can already get the whole number part by casting to int. Keep in mind that the range of decimal is much larger than that of int, so this may throw. And this then also gives you a fairly simple way of getting the fractional part (as decimal): x - (int)x.

• Why do you think that getting the lengths of the two parts is something that should be easy? Is there some class of programs where this is a common operation?

You're right, it wouldn't be useful as an integer as it could not differentiate between 1.5m and 1.05m, it would have to be some other kind of data type, maybe a string.

Yes, I can get the whole part easily by casting, but the decimal part is trickier. So I thought some properties could come in handy and be easier to use.

We have a web application where the users enter quantity (of invoice articles) and wanted to count the amount of decimals for data validation because a third-party API has a limit of three decimals.

@tannergooding

The signature as given wouldn't work/be useful, IMO.

I agree. It would have to be some other data type than int.

[svick]

We have a web application where the users enter quantity (of invoice articles) and wanted to count the amount of decimals for data validation because a third-party API has a limit of three decimals.

I think an an efficient and still fairly clear way to do that is Math.Round(x, 3) == x. (Though you might also have to take care of trailing zeroes, since those are not considered by the == operator.)

[tannergooding]

I'd agree with svick here. If all you're wanting to do is validation or ensuring user inputs meet the requirements, then there are much better ways to do that then trying to get the integer and fractional parts.

If you want to get something that's rounded to 3 digits, you have Math.Round. You can likewise trivially create your own string that's limited to 3 digits using ToString() and a relevant standard or custom numeric format string (ToString("F3") will give you exactly 3 fractional digits every time).

Given that this is decimal, you could also do something like Multiply by 1000, Truncate, and Divide by 1000 or one of many other options to get the right stuff.

If you do want to split into just integer/fractional parts; you can simply:

var integerPart = decimal.Truncate(x);
var fractionalPart = x - integerPart;

[vanillajonathan]

I've rewritten the API proposal to instead provide a Scale property like SqlDecimal.

[tannergooding]

This seems like a reasonable thing to expose, uses the existing terminology from the existing constructor, and is a simple extract of the underlying data.

[GSPP]

Related:

• Make decimal API more complete (number of decimal digits, equality, negative zero) #25715

Although this issue was closed, these proposed features still seem like a good idea to me.

[tannergooding]

We had explicitly determined -0.0 was not a concept that should be exposed from decimal. It doesn't expose other key concepts like infinity or nan and so will never support things like transcedentals, etc.

Decimal is explicitly a "currency" type (and Currency probably would've been a better name, but hindsight is 20/20).

If we want to have concepts like these, then we are likely better off writing up a proposal and implementing the IEEE 754 decimal32, decimal64, and decimal128 types. These types are part of an industry standard, support the same concepts and operations as the binary floating-point types, and are generally more efficient to operate on and work with.

[terrajobst]

Video

• Looks good as proposed

namespace System
{
    public partial struct Decimal
    {
        public byte Scale { get; }
    }
}

[danmoseley]

@vanillajonathan are you interested in offering a PR or should we mark up for grabs?

[vanillajonathan]

@danmoseley Mark it as up for grabs.

[MichalPetryka]

Could I be assigned to this? I'll do it now.

[tannergooding]

Assigned out, thanks @MichalPetryka!

-- Noting we already discussed the needs/implementation here (new API, doc comment, and basic tests) in the C# Community Discord.