Fields

Fields

A field is a member that represents a variable associated with an object or class. A field-declaration introduces one or more fields of a given type.

field-declaration:
attributes_opt field-modifiers_opt type variable-declarators ;

field-modifiers:
field-modifier
field-modifiers field-modifier

field-modifier:
new
public
protected
internal
private
static
readonly
volatile

variable-declarators:
variable-declarator
variable-declarators , variable-declarator

variable-declarator:
identifier
identifier = variable-initializer

variable-initializer:
expression
array-initializer

A field-declaration may include a set of attributes (‎17), a new modifier (‎10.2.2), a valid combination of the four access modifiers (‎10.2.3), a static modifier (‎10.4.1). In addition, a field-declaration may include a readonly modifier (‎10.4.2) or a volatile modifier (‎10.4.3) but not both. The attributes and modifiers apply to all of the members declared by the field-declaration.

The type of a field-declaration specifies the type of the members introduced by the declaration. The type is followed by a list of variable-declarators, each of which introduces a new member. A variable-declarator consists of an identifier that names the member, optionally followed by an "=" token and a variable-initializer (‎10.4.5) that gives the initial value of the member.

The type of a field must be at least as accessible as the field itself (‎3.5.4).

The value of a field is obtained in an expression using a simple-name (‎7.5.2) or a member-access (‎7.5.4). The value of a non-readonly field is modified using an assignment (‎7.13). The value of a non-readonly field can be both obtained and modified using postfix increment and decrement operators (‎7.5.9) and prefix increment and decrement operators (‎7.6.7).

A field declaration that declares multiple fields is equivalent to multiple declarations of single fields with the same attributes, modifiers, and type. For example

class A

is equivalent to

class A

Static and instance fields

When a field-declaration includes a static modifier, the fields introduced by the declaration are static fields. When no static modifier is present, the fields introduced by the declaration are instance fields. Static fields and instance fields are two of the several kinds of variables (‎5) supported by C#, and are at times referred to as static variables and instance variables.

A static field identifies exactly one storage location. No matter how many instances of a class are created, there is only ever one copy of a static field. A static field comes into existence when the type in which it is declared is loaded, and ceases to exist when the type in which it is declared is unloaded.

Every instance of a class contains a separate set of all instance fields of the class. An instance field comes into existence when a new instance of its class is created, and ceases to exist when there are no references to that instance and the destructor of the instance has executed.

When a field is referenced in a member-access (‎7.5.4) of the form E.M, if M is a static field, E must denote a type that has a field M, and if M is an instance field, E must denote an instance of a type that has a field M.

The differences between static and instance members are discussed further in ‎10.2.5.

Readonly fields

When a field-declaration includes a readonly modifier, the fields introduced by the declaration are readonly fields. Direct assignments to readonly fields can only occur as part of the declaration or in an instance constructor (for readonly non-static fields) or static constructor (for readonly static fields) in the same class. (A readonly field can be assigned multiple times in these contexts.) Specifically, direct assignments to a readonly field are permitted only in the following contexts:

In the variable-declarator that introduces the field (by including a variable-initializer in the declaration).

For an instance field, in the instance constructors of the class that contains the field declaration, or for a static field, in the static constructor of the class the that contains the field declaration. These are also the only contexts in which it is valid to pass a readonly field as an out or ref parameter.

Attempting to assign to a readonly field or pass it as an out or ref parameter in any other context is an error.

Using static readonly fields for constants

A static readonly field is useful when a symbolic name for a constant value is desired, but when the type of the value is not permitted in a const declaration, or when the value cannot be computed at compile-time. In the example

public class Color

}

the Black, White, Red, Green, and Blue members cannot be declared as const members because their values cannot be computed at compile-time. However, declaring them as static readonly fields instead has much the same effect.

Versioning of constants and static readonly fields

Constants and readonly fields have different binary versioning semantics. When an expression references a constant, the value of the constant is obtained at compile-time, but when an expression references a readonly field, the value of the field is not obtained until run-time. Consider an application that consists of two separate programs:

namespace Program1

}

namespace Program2

}
}

The Program1 and Program2 namespaces denote two programs that are compiled separately. Because Program1.Utils.X is declared as a static readonly field, the value output by the Console.WriteLine statement is not known at compile-time, but rather is obtained at run-time. Thus, if the value of X is changed and Program1 is recompiled, the Console.WriteLine statement will output the new value even if Program2 isn't recompiled. However, had X been a constant, the value of X would have been obtained at the time Program2 was compiled, and would remain unaffected by changes in Program1 until Program2 is recompiled.

Volatile fields

When a field-declaration includes a volatile modifier, the fields introduced by the declaration are volatile fields.

For non-volatile fields, optimization techniques that reorder instructions can lead to unexpected and unpredictable results in multi-threaded programs that access fields without synchronization such as that provided by the lock-statement (‎8.12). These optimizations can be performed by the compiler, the runtime system, or by hardware.

For volatile fields, such reordering optimizations are restricted so that a store into a field cannot be moved forward across a store into a volatile field, and the evaluation of a field cannot be moved backward across the evaluation of a volatile field.

The type of a volatile field must be one of the following:

A reference-type.

The type byte, sbyte, short, ushort, int, uint, char, float, or bool.

An enum-type with an enum base type of byte, sbyte, short, ushort, int, or uint.

Field initialization

The initial value of a field, whether it be a static field or an instance field, is the default value (‎5.2) of the field's type. It is not possible to observe the value of a field before this default initialization has occurred, and a field is thus never "uninitialized". The example

class Test
, i = ', b, t.i);
}
}

produces the output

b = False, i = 0

because b and i are both automatically initialized to default values.

Variable initializers

Field declarations may include variable-initializers. For static fields, variable initializers correspond to assignment statements that are executed during class initialization. For instance fields, variable initializers correspond to assignment statements that are executed when an instance of the class is created.

The example

class Test
, i = , s = ', x, a.i, a.s);
}
}

produces the output

x = 1.414213562373095, i = 100, s = Hello

because an assignment to x occurs when static field initializers execute and assignments to i and s occur when the instance field initializers execute.

The default value initialization described in ‎10.4.4 occurs for all fields, including fields that have variable initializers. Thus, when a class is initialized, all of its static fields are first initialized to their default values, and then the static field initializers are executed in textual order. Likewise, when an instance of a class is created, all of its instance fields are first initialized to their default values, and then the instance field initializers are executed in textual order.

It is possible for static fields with variable initializers to be observed in their default value state. However, this is strongly discouraged as a matter of style. The example

class Test
, b = ', a, b);
}
}

exhibits this behavior. Despite the circular definitions of a and b, the program is legal. It produces the output

a = 1, b = 2

because the static fields a and b are initialized to 0 (the default value for int) before their initializers are executed. When the initializer for a runs, the value of b is zero, and so a is initialized to 1. When the initializer for b runs, the value of a is already 1, and so b is initialized to 2.

Static field initialization

The static field variable initializers of a class correspond to a sequence of assignments that are executed at an implementation-dependent time prior to the static constructor for the class (if any) and prior to the first use of a static field of that class. The static field variable initializers are executed in the textual order in which they appear in the class declaration. The class initialization process is described further in ‎10.11.

Instance field initialization

The instance field variable initializers of a class correspond to a sequence of assignments that are executed immediately upon entry to any one of the instance constructors (‎10.10.1) of the class. The variable initializers are executed in the textual order in which they appear in the class declaration. The class instance creation and initialization process is described further in ‎10.10.

A variable initializer for an instance field cannot reference the instance being created. Thus, it is an error to reference this in a variable initializer, as it is an error for a variable initializer to reference any instance member through a simple-name. In the example

class A

the variable initializer for y is in error because it references a member of the instance being created.