37

Compiler error CS0283 indicates that only the basic POD types (as well as strings, enums, and null references) can be declared as const. Does anyone have a theory on the rationale for this limitation? For instance, it would be nice to be able to declare const values of other types, such as IntPtr.

I believe that the concept of const is actually syntactic sugar in C#, and that it just replaces any uses of the name with the literal value. For instance, given the following declaration, any reference to Foo would be replaced with "foo" at compile time.

const string Foo = "foo";

This would rule out any mutable types, so maybe they chose this limitation rather than having to determine at compile time whether a given type is mutable?

Helen
  • 87,344
  • 17
  • 243
  • 314
Charlie
  • 44,214
  • 4
  • 43
  • 69

6 Answers6

36

From the C# specification, chapter 10.4 - Constants:
(10.4 in the C# 3.0 specification, 10.3 in the online version for 2.0)

A constant is a class member that represents a constant value: a value that can be computed at compile time.

This basically says that you can only use expressions that consists solely of literals. Any calls to any methods, constructors (that cannot be represented as pure IL literals) cannot be used, as there is no way for the compiler to do that execution, and thus compute the results, at compile time. Also, since there is no way to tag a method as invariant (ie. there is a one-to-one mapping between input and output), the only way for the compiler to do this would be to either analyze the IL to see if it depends on things other than the input parameters, special-case handle some types (like IntPtr), or just disallow every call to any code.

IntPtr, as an example, though being a value type, is still a structure, and not one of the built-in literals. As such, any expression using an IntPtr will need to call code in the IntPtr structure, and this is what is not legal for a constant declaration.

The only legal constant value type example I can think of would be one that is initialized with zeroes by just declaring it, and that's hardly useful.

As for how the compiler treats/uses constants, it will use the computed value in place of the constant name in the code.

Thus, you have the following effect:

  • No reference to the original constant name, class it was declared in, or namespace, is compiled into the code in this location
  • If you decompile the code, it will have magic numbers in it, simply because the original "reference" to the constant is, as mentioned above, not present, only the value of the constant
  • The compiler can use this to optimize, or even remove, unnecessary code. For instance, if (SomeClass.Version == 1), when SomeClass.Version has the value of 1, will in fact remove the if-statement, and keep the block of code being executed. If the value of the constant is not 1, then the whole if-statement and its block will be removed.
  • Since the value of a constant is compiled into the code, and not a reference to the constant, using constants from other assemblies will not automagically update the compiled code in any way if the value of the constant should change (which it should not!)

In other words, with the following scenario:

  1. Assembly A, contains a constant named "Version", having a value of 1
  2. Assembly B, contains an expression that analyzes the version number of assembly A from that constant and compares it to 1, to make sure it can work with the assembly
  3. Someone modifies assembly A, increasing the value of the constant to 2, and rebuilds A (but not B)

In this case, assembly B, in its compiled form, will still compare the value of 1 to 1, because when B was compiled, the constant had the value 1.

In fact, if that is the only usage of anything from assembly A in assembly B, assembly B will be compiled without a dependency on assembly A. Executing the code containing that expression in assembly B will not load assembly A.

Constants should thus only be used for things that will never change. If it is a value that might or will change some time in the future, and you cannot guarantee that all other assemblies are rebuilt simultaneously, a readonly field is more appropriate than a constant.

So this is ok:

  • public const Int32 NumberOfDaysInAWeekInGregorianCalendar = 7;
  • public const Int32 NumberOfHoursInADayOnEarth = 24;

while this is not:

  • public const Int32 AgeOfProgrammer = 25;
  • public const String NameOfLastProgrammerThatModifiedAssembly = "Joe Programmer";

Edit May 27th 2016

OK, just got an upvote, so I re-read my answer here and this is actually slightly wrong.

Now, the intention of the C# language specification is everything I wrote above. You're not supposed to use something that cannot be represented with a literal as a const.

But can you? Well, yes....

Let's take a look at the decimal type.

public class Test
{
    public const decimal Value = 10.123M;
}

Let's look at what this class looks like really when looked at with ildasm:

.field public static initonly valuetype [mscorlib]System.Decimal X
.custom instance void [mscorlib]System.Runtime.CompilerServices.DecimalConstantAttribute::.ctor(int8, uint8, uint32, uint32, uint32) = ( 01 00 01 00 00 00 00 00 00 00 00 00 64 00 00 00 00 00 )

Let me break it down for you:

.field public static initonly

corresponds to:

public static readonly

That's right, a const decimal is actually a readonly decimal.

The real deal here is that the compiler will use that DecimalConstantAttribute to work its magic.

Now, this is the only such magic I know of with the C# compiler but I thought it was worth mentioning.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • 1
    Obviously you can't do this but *hypothetically speaking*, say we had a value-type-returning static method that was marked with the [Pure] attribute and the compiler actually enforced it (it doesn't currently). Could the language designers at least *theoretically* allow a const to be initialized with static value-type-returning pure method (with actual [Pure] attribute enforcement) as long as the arguments were nothing but literals? It seems like they could just run it with the literal args, get the result which is obviously not going to change and sub in the value. Am I overlooking something? – KatDevsGames Feb 07 '15 at 22:24
  • `In this case, assembly B, in its compiled form, will still compare the value of 1 to 1, because when B was compiled, the constant had the value 1` - you still can do the same thing with `public const int AssemblyVersion = 1` in any C# version today, so nothing is wrong with *structures* themselves – Alex Zhukovskiy Dec 23 '15 at 16:41
1

I believe that the concept of const is actually syntactic sugar in C#, and that it just replaces any uses of the name with the literal value

What does the compiler do with const objects in other languages?

You can use readonly for mutable types that me be evaluated at runtime. See this article for the differences.

Mike G
  • 4,232
  • 9
  • 40
  • 66
Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • I guess you could check this using Reflector. – BuddyJoe Jan 14 '09 at 00:40
  • The keyword const might have different effects in different languages, like in C++, where it can be used to guarantee that a method does not change the state of an object, as an example. – Lasse V. Karlsen Jan 14 '09 at 01:01
  • @LasseV.Karlsen, but `const` does mean the same thing in both C(++) and C# for *non-reference* types. So this answer is right when talking about that. Other languages have this concept of “const correctness”. The closest analogue in C# is the immutable pattern combined with `readonly` class members initialized by the constructor. – binki Mar 11 '15 at 18:16
1

Does anyone have a theory on the rationale for this limitation?

If it's allowed to be just a theory, my theory is that const values of primitive types can be expressed at literal opcode parameters in the MSIL ... but the values of other, non-primitive types cannot, because MSIL doesn't have the syntax to express the value of a user-defined type as a literal.

ChrisW
  • 54,973
  • 13
  • 116
  • 224
  • That seems possible, yeah (see also my comment to @IAmCodeMonkey) – Charlie Jan 14 '09 at 00:29
  • The MSIL defines constants in terms of a sequence of bytes. Given a type like e.g. `struct Vector2d {public double X,Y;}`, a compiler could allow declaration of a constant `const Vector2d UnitXVector = {X=1.0, Y=0.0};`, since it could determine the exact sequence of bytes represented by that structure. That would only work, however, for a struct with no private fields; if a struct uses public properties and private backing fields, a compiler could only construct it by figuring out what exactly the properties did. – supercat Jul 10 '14 at 16:29
  • @supercat, are you implying that MSIL can rely on objects being layed out a certain way in memory? Doesn’t the existence of [`StructLayoutAttribute`](https://msdn.microsoft.com/en-us/library/System.Runtime.InteropServices.StructLayoutAttribute%28v=vs.100%29.aspx) imply it can’t? – binki Mar 11 '15 at 18:02
  • 1
    @binki: There's actually a bigger problem, which is that code which compiles a constant using one version of a structure could yield unexpected results if run with a different version of that structure. Microsoft can guarantee that it will never change the `Decimal` type such that the sequence of bytes encapsulated by one `Decimal` value might someday encapsulate a different one, but for most types there would be no way to make such a guarantee. – supercat Mar 11 '15 at 21:19
  • @supercat but they could address that by making sure the CLR itself doesn’t crash if the length of the `byte[]` of compiler-serialized version of the struct does not match—I imagine this sort of ABI break is basically the same as when a parent class removes a parameter from a constructor that an inheriting class was calling. C# doesn’t try to make that hard. And, more importantly, there is already documentation, discussion, and understanding of how `readonly static` is often better `const` (but default method arguments for an `internal` API!) Sounds like this is all about that “pit of success” – binki Mar 11 '15 at 21:42
  • @binki: If the length of the compiler-serialized version of the struct doesn't match, the likelihood that the CLR would be able to run the program in such fashion as to yield desired behavior isn't great; even if the length is right, there's still a risk that layout has changed between versions. IMHO, for a compiler to be willing to serialize a struct, it should be tagged with something that says "the layout of this struct is absolutely positively never going to change". – supercat Mar 11 '15 at 23:49
0

In short, all simple types, enums and strings are immutable but a Struct for instance is not. You can have a Struct with mutable state ( fields, properties, even references to Reference Types). So the compiler can't make sure ( at compile time ) that the internal state of a Struct variable cannot be changed. So the compiler needs to be sure that a type is by definition immutable to be used in a constant expression.

Cagatay Kalan
  • 4,066
  • 1
  • 30
  • 23
0

It seems to me that only value types can be expressed as a constant (with the exception of strings, which stands somewhere between value and object type).

It is OK for me : objects (references) must be allocated on the heap but constants are not allocated at all (since they're replaced at compile time).

Sylvain Rodrigue
  • 4,751
  • 5
  • 53
  • 67
  • 1
    Strings can be used because the compiler can insert IL code to load a string with a given value. Since this is IL magic specially added for strings, they can be used. – Lasse V. Karlsen Jan 14 '09 at 01:14
-1

consts are limited to numbers and strings in C# because the compiler replaces the variable with the literal value in the MSIL. In other words when you write:

const string myName = "Bruce Wayne";
if (someVar == myName)
{
   ...
}

is actually treated as

if (someVar == "Bruce Wayne")
{
   ...
}

and yes, the C# compiler is smart enough to treat the equality operator (==) on strings as 

string1.Equals(string2)
IAmCodeMonkey
  • 1,576
  • 1
  • 11
  • 11
  • Right, what I don't get is why you couldn't declare e.g. a const IntPtr, which could also be replaced at usage points. Perhaps the difference is that an IntPtr would have to be constructed, whereas PODs and strings can be represented directly in the IL. – Charlie Jan 14 '09 at 00:27
  • The compiler would have to execute code in IntPtr to get the final value, and this "execute code to get the value" part would have to be compiled into the code wherever the constant is used, and this is the part that is not allowed. – Lasse V. Karlsen Jan 14 '09 at 01:13