Initialization precedence - const vs readonly vs static readonly

Question

Example 1

private const string _DefaultIconPath = _IconsPath + "default.ico";
private const string _IconsPath = "Icons/";

Value of these strings at runtime:

• _DefaultIconPath: "Icons/default.ico"
• _IconsPath: "Icons/"

---

Example 2

private readonly string _DefaultIconPath = _IconsPath + "default.ico";
private readonly string _IconsPath = "Icons/";

Compile time error:

A field initializer cannot reference the non-static field, method, or property '_IconsPath'

---

Example 3

private static readonly string _DefaultIconPath = _IconsPath + "default.ico";
private static readonly string _IconsPath = "Icons/";

Value of these strings at runtime:

• _DefaultIconPath: "default.ico" (_IconsPath evaluated to null)
• _IconsPath: "Icons/"

---

Question

Why doesn't the compiler throw a compilation error in example 3 similar to example 2?

The order of the declaration matters in the case of static readonly field definitions, but not in the case of const field definitions.

Edit:

I understand why the strings are initialized to those specific values. What I don't understand is why Example 2 throws a compilation error, forcing initialization to occur in a constructor rather than in the declaration of the variables (which makes perfect sense), but Example 3 doesn't behave in the same manner. Wouldn't it make sense to throw the same compilation error forcing the initialization to occur in a static constructor?

---

Another Example

private static string test = test2;
private static string test2 = test;

This example demonstrates what I'm trying to explain. The compiler could force initialization of static state in a static constructor (as is does for instance variables). Why does the compiler allow it (or why does the compiler disallow this for instance variables)?

Answer 1

There are two unrelated problems.

1. Compilation Error

Static members do not require an instance of a class to obtain the values. This is why referencing a static member from a static member does not cause problems.

When initializing instance members, you cannot reference this when attempting to initialize members unless you do so from the constructor.

Because you have not marked the fields in Example 2 as static, you must first instantiate an instance of whatever object contains them prior to referencing those members.

Just because they are readonly does not mean that they are static. Readonly fields can be instantiated in their declaration or the constructor of the class, but they are not shared across all instances of the class, nor can they be accessed without proper instantiation (assuming they aren't explicitly made static like Example 3).

2. Null Value

The reason _IconsPath is null in Example 3 is because the fields are declared and instantiated sequentially. Reverse the order and you'll see that it is no longer null.

Answer 2

Example 3 uses static variables and so it is allowed.

Example 2 fails because C# does not allow a variable initializer to refer the instance being created. Refer Jon Skeet's explanation here.

You could do this instead:

public class YourClass {
  private readonly string _IconsPath;
  private readonly string _DefaultIconsPath;

  public YourClass() {
    _IconsPath = "Icons/";
    _DefaultIconPath = _IconsPath + "default.ico";
  }
}

Answer 3

In example 2 '_IconsPath' isn't initialized, and can not be used.

In example 3, you are accessing a static field (as you know). It perfectly fine says MSDN A static method, field, property, or event is callable on a class even when no instance of the class has been created.

See it here

Update: Example 3: It's the same as:

private static readonly string _DefaultIconPath = MyStaticClass._IconsPath + "default.ico";
private static readonly string _IconsPath = "Icons/";

The point is that your not using a field (belove that isn't initialized, you are using an ("other"/"new") static class (That dosn't have to be create before you used it in a static way).