The SLAR (vol2) on System.Runtime.CompilerServices. DecimalConstantAttribute

  • Article

Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on DecimalConstantAttribute.

RJ (Rex Jaeschke)

The metadata does not directly support the representation of constants of type System.Decimal. As a result, in the code generated by the C# (and VB) compiler, they are stored as an

attribute using the type DecimalConstantAttribute. Consider the following C# code:

public class Test

{

private const decimal d = 12.3456m;

}

The relevant MSIL generated is

.field private static initonly valuetype [mscorlib]System.Decimal d

.custom instance void

[mscorlib]

System.Runtime.CompilerServices.DecimalConstantAttribute::.ctor(

uint8, uint8, uint32, uint32, uint32) = ( … hex bytes … )

This type is not intended to be used directly by programmers, but rather by compiler writers,

based on the programmer’s use of some language syntax (such as the keywords const

decimal in C#).

Note that it is expected that a future implementation of the CLI will support an alternate

representation of the decimal type, which has a much larger range, and a scale that exceeds

eight bits. As such, new constructors and methods are likely to be added to this type, as well as

to System.Decimal.

DT

This attribute has been a hot topic in ECMA discussions. A new IEEE 128-bit decimal

representation offers more range/precision (in the same number of bits!) than the current CLR

implementation. If CLR were to support this new IEEE decimal in the future, this attribute will

present a problem because the IEEE decimal’s scale is wider than the byte type of the

constructor’s scale parameter. It is likely that the parameter types of the constructor will be

widened and/or additional constructors added in a future release to make an IEEE decimal

implementation an option for a future CLR release.