A comment on a Stack Overflow post recently got me delving into constants a bit more thoroughly than I have done before.
Const fields
I’ve been aware for a while that although you can specify decimal field as a const in C#, it’s not really const as far as the CLR is concerned. Let’s consider this class to start with:
class Test
{
const int ConstInt32 = 5;
const decimal ConstDecimal = 5;
}
Firstly, csc gives us a warning about ConstDecimal but not about ConstInt32:
Test.cs(4,19): warning CS0414: The field ‘Test.ConstDecimal’ is assigned but its value is never used
The Roslyn compiler (rcsc) doesn’t warn about either of the fields. This is just a curiosity, really – but it already shows that there’s some difference in how they’re compiled. When we delve into the IL, the difference is much more pronounced:
.class private auto ansi beforefieldinit Test
extends [mscorlib]System.Object
{
.field private static literal int32 ConstInt32 = int32(0x00000005)
.field private static initonly valuetype [mscorlib]System.Decimal ConstDecimal
.custom instance void [mscorlib]DecimalConstantAttribute::.ctor
(uint8, uint8, uint32, uint32, uint32) =
( 01 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 00 00 )
// Skip the parameterless constructor
.method private hidebysig specialname rtspecialname static
void .cctor() cil managed
{
// Code size 12 (0xc)
.maxstack 8
IL_0000: ldc.i4.5
IL_0001: newobj instance void [mscorlib]System.Decimal::.ctor(int32)
IL_0006: stsfld valuetype [mscorlib]System.Decimal Test::ConstDecimal
IL_000b: ret
} // end of method Test::.cctor
} // end of class Test
First things to note:
ConstInt32 has the literal constraint in IL. From ECMA 335, I.8.6.1.2:
The literal constraint promises that the value of the location is actually a fixed value
of a built-in type. The value is specified as part of the constraint. Compilers are
required to replace all references to the location with its value, and the VES therefore
need not allocate space for the location. This constraint, while logically applicable to
any location, shall only be placed on static fields of compound types. Fields that are
so marked are not permitted to be referenced from CIL (they shall be in-lined to their
constant value at compile time), but are available using reflection and tools that
directly deal with the metadata.
Whereas ConstDecimal only has the initonly constraint. Again, from ECMA 335:
The init-only constraint promises (hence, requires) that once the location has been
initialized, its contents never change. Namely, the contents are initialized before any
access, and after initialization, no value can be stored in the location. The contents are
always identical to the initialized value (see §I.8.2.3). This constraint, while logically
applicable to any location, shall only be placed on fields (static or instance) of
compound types.
(Here “compound type” just means “not an array type” – although in quite a confusing manner. I would ignore it if I were you.)
Next, note that there’s an attribute (System.Runtime.CompilerServices.DecimalConstantAttribute – I’ve taken the namespace off in the listing for the sake of readability) applied to the field, which tells anything consuming the assembly that it should be a constant, and what its value is. Indeed, if you’re very careful, you can create your own “constants” like this:
[DecimalConstant((byte)0, (byte)0, (uint)0, (uint)0, (uint) 5)] public static readonly decimal ConstDecimal;
That field declaration will be treated as a constant in other assembles – but not within the same assembly. So printing ConstDecimal within the same assembly will result in 0 (unless you change it to another value in the static initializer) whereas printing Test.ConstDecimal in a different assembly will result in 5. (It won’t even touch the field at execution time.) I’m sure I can work out some nasty ways of abusing that, if I try hard enough.
Note that the casts to uint are important – if you accidentally call the attribute constructor with a (byte, byte, int, int, int), the compiler doesn’t recognize it. (Interesting, the latter was only introduced in .NET 2.0. I’ve no idea why.)
Amusingly, you can combine the two:
[DecimalConstant((byte)0, (byte)0, (uint)0, (uint)0, (uint) 5)] public const decimal ConstDecimal = 10;
In this case, the IL contains both DecimalConstant attributes, despite the fact that it’s only legal to apply one. (AllowMultiple is false on its AttributeUsage.) The compiler appears to pick the one specified by the value rather than manually applied, which is slightly disappointing, but of no real importance.
Optional parameters
In the case of const fields, we’ve really only cared about what the compiler does. Let’s try something where both the compiler and the framework can get involved: optional parameters.
Again, let’s write a little class to demonstrate how the default values of optional parameters are encoded in IL:
public class Test
{
public void PrintInt32(int x = 10)
{
Console.WriteLine(x);
}
public void PrintDecimal(decimal d = 10m)
{
Console.WriteLine(d);
}
}
The important bits of the generated IL are:
.method public hidebysig instance void PrintInt32([opt] int32 x) cil managed
{
.param [1] = int32(0x0000000A)
...
} // end of method Test::PrintInt32
.method public hidebysig instance void PrintDecimal(
[opt] valuetype [mscorlib]System.Decimal d) cil managed
{
.param [1]
.custom instance void [mscorlib] DecimalConstantAttribute::.ctor
(uint8, uint8, uint32, uint32, uint32) =
( 01 00 00 00 00 00 00 00 00 00 00 00 0A 00 00 00 00 00 )
...
} // end of method Test::PrintDecimal
Again, we have a DecimalConstantAttribute to describe the default value for the decimal parameter, whereas . If you call the method but don’t specify an argument, the compiler notes the DecimalConstantAttribute applied to the method parameter, and constructs the value in the calling code. That’s not the only way of observing the default value, however – you can do it with reflection, too:
public static void Main()
{
var method = typeof(Test).GetMethod("PrintDecimal");
var parameter = method.GetParameters()[0];
Console.WriteLine("Default value: {0}", parameter.DefaultValue);
}
As you’d expect, that prints a default value of 10. There’s no direct equivalent of DefaultValue for FieldInfo – there’s GetRawConstantValue() but that only works for constants that the CLR is directly aware of – it fails for a field like const decimal Foo = 10m , with an InvalidOperationException. I’ll talk more about CLR constants later.
Now let’s try something a bit more tricksy though… C# doesn’t support DateTime literals, unlike VB – but there’s a DateTimeConstantAttribute – what happens if we try to apply that ourselves? Let’s see…
public void PrintDateTime
([Optional, DateTimeConstant(635443315962469079L)] DateTime date)
{
Console.WriteLine(date);
}
So if we call PrintDateTime(), what does that print? Well (leaving aside the formatting – the examples below use the UK default formatting):
- With
csc.exe(the “old” C# compiler), with the call in the same assembly as the method declaration, it prints 01/01/0001 00:00:00 - With
csc.exe, with the call in a different assembly to the method declaration, it prints22/08/2014 19:13:16 - With
rcsc.exe(Roslyn), it prints22/08/2014 19:13:16regardless of where it’s called from - If you call it dynamically (
dynamic d = new Test(); d.PrintDateTime();) it prints22/08/2014 19:13:16regardless of the compiler – at least with the version of .NET I’m using. It may well vary by version.
In every case, printing out the ParameterInfo.DefaultValue gives the right answer: the framework doesn’t care whether or not the compiler understands the attribute.
In case you’re wondering why I didn’t mention this possibility for constant fields – I tried it, and it didn’t work, even in Roslyn. For some reason optional parameters are treated as more “special” than constant fields.
Having got this far, why stop with DateTime? The DateTimeConstantAttribute class derives from CustomConstantAttribute (whereas DecimalConstantAttribute just derives from Attribute). So can I introduce my own constant attributes? Noda Time seems to be an obvious candidate for this – let’s try for a LocalDateConstantAttribute:
[AttributeUsage(AttributeTargets.Parameter | AttributeTargets.Field)]
public class LocalDateConstantAttribute : CustomConstantAttribute
{
private readonly LocalDate value;
public LocalDateConstantAttribute(int year, int month, int day)
{
value = new LocalDate(year, month, day);
}
public override object Value { get { return value; } }
}
...
public void PrintLocalDate(
[Optional, LocalDateConstant(2014, 8, 22)] LocalDate date)
{
Console.WriteLine(date);
}
How does this fare? Not so well, unfortunately:
– With a normal method call (regardless of assembly), it prints 01 January 1970 (the default value for a LocalDate in Noda Time 1.3)
– With a dynamic method call it prints 01 January 1970
– With reflection (i.e. using ParameterInfo.DefaultValue) the framework does construct the appropriate LocalDate, which seems logical as it’s presumably just using the Value property of the attribute
So, there’s still work to be done there. I think it would be feasible to do this in a general way, if it’s acceptable for an exception to be thrown if the Value property returns an incompatible type of object to the parameter type. The great thing is that Roslyn is open source, so I should be able to spike this myself, right? How hard can it be? (Cue howls of derisive laughter from the Roslyn team, who will know much better than I how hard it’s likely to really be.)
CLR constants and attribute arguments
So with constant fields, it was all down to the compiler, really. For optional parameters, it’s mostly still down to the compiler, but with framework support for reflection. What about attribute arguments? They’re the other notable aspect of C# which requires compile-time constants. For example, this is fine:
[Description("This is a constant")]
But this is not:
[Description("Initialized at " + DateTime.Now)]
Intriguingly, this is fine too:
[ContractClass(typeof(Foo))]
… despite the fact that
const Type ConstType = typeof(Foo);
isn’t valid. The only constant expression which is valid for type Type is null. So in section 17.2 of the C# 5 specification, Type is explicitly called out:
An expression E is an attribute-argument-expression if all of the following statements are true:
- The type of E is an attribute parameter type (§17.1.3).
- At compile-time, the value of E can be resolved to one of the following:
- A constant value.
- A
System.Typeobject.- A one-dimensional array of attribute-argument-expressions.
(Interestingly, there’s no indication that I can see that the value of E has to be obtained via typeof, in the spec – clearly [ContractClass(Type.GetType("TodayIs" + DateTime.Today.Day))] should be invalid, but I can’t currently see which bit of the spec that violates. Something to be tightened up, potentially.)
And the “attribute parameter type” part – section 17.1.3 – looks like this:
The types of positional and named parameters for an attribute class are limited to the attribute parameter types, which are:
- One of the following types:
bool,byte,char,double,float,int,long,sbyte,short,string,uint,ulong,ushort.- The type
object.- The type
System.Type.- An enum type, provided it has public accessibility and the types in which it is nested (if any) also have public accessibility (§17.2).
- Single-dimensional arrays of the above types.
Oops – no decimal. Note that the type of E that has to be one of those types, as well as the parameter type… so it doesn’t help to have a parameter of type object and then try to pass a constant decimal value as the argument.
Basically, attributes arguments are sufficiently low-level that the CLR itself wants to know about them – and while it has a deep knowledge of Type, string and the primitive value types, it doesn’t have much knowledge about decimal (or at least, it isn’t required to). Attribute arguments can’t use funky “custom constant” attributes to specify values like decimal or DateTime – you really are limited to the types that the CLR knows about. In a future version it’s not inconceivable that this could be broadened, but at the moment it’s pretty strict.
Conclusion
So, it turns out the idea of a constant isn’t terribly constant in itself. We have:
- Constant fields, which are primarily a compile-time concern, and therefore language-specific.
- Optional parameter default values, which feel like they ought to be just like constant fields (in that a value specified in one place is substituted in another) but apparently have a bit more support in the C# compiler… and more reflection support too.
- Attribute arguments, which are the strictest form of constant I’ve found so far, in that they have to correspond to a small set of CLR “special” types.
I didn’t even talk about constant expressions (section 7.19 of the C# 5 spec) much in this post – maybe I’ll delve into those in more detail in another post.
Unlike my normal day-dreaming about changing the compiler, I think I really might have a crack at Roslyn for supporting arbitrary optional parameters – it feels like it could potentially be genuinely useful (which is also unlike most of my idle speculation).
So next time you ask yourself whether something is a constant, you should start off by asking yourself what you mean by “constant” in the first place.
Jon Skeet's coding blog 