What is the purpose of Decimal.One, Decimal.Zero, Decimal.MinusOne in .Net

Question

Simple question - why does the Decimal type define these constants? Why bother?

I'm looking for a reason why this is defined by the language, not possible uses or effects on the compiler. Why put this in there in the first place? The compiler can just as easily in-line 0m as it could Decimal.Zero, so I'm not buying it as a compiler shortcut.

Solution 1

Small clarification. They are actually static readonly values and not constants. That has a distinct difference in .Net because constant values are inlined by the various compilers and hence it's impossible to track their usage in a compiled assembly. Static readonly values however are not copied but instead referenced. This is advantageous to your question because it means the use of them can be analyzed.

If you use reflector and dig through the BCL, you'll notice that MinusOne and Zero are only used with in the VB runtime. It exists primarily to serve conversions between Decimal and Boolean values. Why MinusOne is used coincidentally came up on a separate thread just today (link)

Oddly enough, if you look at the Decimal.One value you'll notice it's used nowhere.

As to why they are explicitly defined ... I doubt there is a hard and fast reason. There appears to be no specific performance and only a bit of a convenience measure that can be attributed to their existence. My guess is that they were added by someone during the development of the BCL for their convenience and just never removed.

EDIT

Dug into the const issue a bit more after a comment by @Paleta. The C# definition of Decimal.One uses the const modifier however it is emitted as a static readonly at the IL level. The C# compiler uses a couple of tricks to make this value virtually indistinguishable from a const (inlines literals for example). This would show up in a language which recognize this trick (VB.Net recognizes this but F# does not).

Solution 2

Some .NET languages do not support decimal literals, and it is more convenient (and faster) in these cases to write Decimal.ONE instead of new Decimal(1).

Java's BigInteger class has ZERO and ONE as well, for the same reason.

Comments

[fuzzy-waffle]

Your argument hurts my head. They are numbers, they only become magic numbers when you start attaching random meaning to them such as -1 means do the dishes and 1 means bake cakes. Decimal.One is just as magical as 1 but arguably harder to read (but perhaps more optimal).

[Mitkins]

my point was that if someone types Decimal.Zero, they are more likely to have done that deliberately because Zero has some meaning - rather than just arbitrarily setting it to 0

[fuzzy-waffle]

I take issue with saying assigning something to 0 is arbitrary. It makes sense for enumerations with symbolic constants being mapped to numbers but for numbers mapped to numbers seems pretty insane. Sometimes 0 is really... zero. Units on the other hand would be a nice construct. 1km != 1.

[Benson]

Saying Decimal.Zero is just as arbitrary as saying 0.0. If we were talking about something that changes on an operating system level, like "/" vs some library constant that describes the filesystem separator, it would make sense, but Decimal.Zero is always just 0.0.

[Rob P.]

Can someone explain this to me? 6 up votes means it's got to be a good answer - but: How does a .Net language that doesn't support decimal as a datatype benefit from having a shared read-only property that returns a decimal and is defined as part of the decimal class?

[Mitkins]

Damn, it was just my opinion. I thought I made that clear :-(

[Niki]

He probably meant that if a language doesn't have decimal literals, using a constant would be more efficient than converting an int literal to a decimal. Every .NET language supports the System.Decimal datatype, it's part of the CLR.

[sawyer seguin]

yeah Niki that is what I wanted to say. You can of course use System.Decimal in all .NET languages, but some support it better (like C# which has a decimal keyword and decimal literals) and some worse. Sorry, English is not my native language...

[Rob P.]

Thank you for the explanation. That makes sense now.

[Daniel Pryden]

What are you talking about? You're doing bad math with inexact values and then using the division operator to come up with your epsilon? What makes you think that the result will always be off by exactly 0.01, and not (for example) 0.005? If these values represent money, I'd be scared to do business with your application.

[Hassen]

:) I'm not calculating an end result, i have to give the value of (y) for the rounded format. how will you do it ?

[Ian Ringrose]

I have in a past job be told I must have consts for numbers like "1", so as to advoid magic numbers in my code. I wish all coding standards starting of my saying the reader must have a brain!

[Niraj Savaliya]

It is incorrect that those values are readonly, looking at the .net framework Decimal metada you can see the following [DecimalConstant(0, 0, 4294967295, 4294967295, 4294967295)] public const decimal MaxValue = 79228162514264337593543950335m; [DecimalConstant(0, 128, 0, 0, 1)] public const decimal MinusOne = -1m;

[JaredPar]

@Paleta, no they are readonly. I've verified this by looking at the metadata and the MSDN page for hte values. msdn.microsoft.com/en-us/library/system.decimal.one(VS.80).a‌​spx

[Niraj Savaliya]

I have to disagree with you and your answer, look at the reflected mscorlib.dll code here reflector.webtropy.com/default.aspx/4@0/4@0/DEVDIV_TFS/Dev10‌​/… those are declared as constants, MSDN is incorrect

[JaredPar]

@Paleta this is a case where C# is lying to you. Even though C# allows you to declare a decimal as a const it will still emit it as a static readonly. You can verify this by adding a decimal constant to a program and then examining the IL of the program

[JaredPar]

@Paleta updated my answer to discuss a bit what's going on here.

[Niraj Savaliya]

Well, I just saw that on the IL is declared as field static initonly, are all const in C# translated into static readonly fields? Thanks for the clarification

[JaredPar]

@Paleta i shared the same confusion as you. I had to sit down for a few minutes and play around with the generated IL and C# source to understand what was going on here. For your question though, no the majority of C# constants are emitted as .literal values. It appears that only DateTime and Decimal are emitted in this mixed manner

[mireazma]

Although it may not be the real reason behind Decimal.Zero et al. this answer makes sense. Take int.MaxValue for instance, which is just an alias for a specific value but it conveys the meaning when assigned instead of the actual value. Ok, the difference is that you wouldn't have to remember the value but then why would you?