The checked and unchecked statements

The checked and unchecked statements are used to control the overflow checking context for integral-type arithmetic operations and conversions.

checked-statement:
checked block

unchecked-statement:
unchecked block

The checked statement causes all expressions in the block to be evaluated in a checked context, and the unchecked statement causes all expressions in the block to be evaluated in an unchecked context.

The checked and unchecked statements are precisely equivalent to the checked and unchecked operators (§7.6.12), except that they operate on blocks instead of expressions.

The lock statement

The lock statement obtains the mutual-exclusion lock for a given object, executes a statement, and then releases the lock.

lock-statement:
lock (expression) embedded-statement

The expression of a lock statement must denote a value of a type known to be a reference-type. No implicit boxing conversion (§6.1.7) is ever performed for the expression of a lock statement, and thus it is a compile-time error for the expression to denote a value of a value-type.

A lock statement of the form

lock (x)...

where x is an expression of a reference-type, is precisely equivalent to

bool __lockWasTaken = false;
try {
System.Threading.Monitor.Enter(x, ref __lockWasTaken);
...
}
finally {
if (__lockWasTaken) System.Threading.Monitor.Exit(x);
}

except that x is only evaluated once.

While a mutual-exclusion lock is held, code executing in the same execution thread can also obtain and release the lock. However, code executing in other threads is blocked from obtaining the lock until the lock is released.

Locking System.Type objects in order to synchronize access to static data is not recommended. Other code might lock on the same type, which can result in deadlock. A better approach is to synchronize access to static data by locking a private static object. For example:

class Cache
{
private static readonly object synchronizationObject = new object();

public static void Add(object x) {
lock (Cache.synchronizationObject) {
...
}
}

public static void Remove(object x) {
lock (Cache.synchronizationObject) {
...
}
}
}

The using statement

The using statement obtains one or more resources, executes a statement, and then disposes of the resource.

using-statement:
using (resource-acquisition) embedded-statement

resource-acquisition:
local-variable-declaration
expression

A resource is a class or struct that implements System.IDisposable, which includes a single parameterless method named Dispose. Code that is using a resource can call Dispose to indicate that the resource is no longer needed. If Dispose is not called, then automatic disposal eventually occurs as a consequence of garbage collection.

If the form of resource-acquisition is local-variable-declaration then the type of the local-variable-declaration must be either dynamic or a type that can be implicitly converted to System.IDisposable. If the form of resource-acquisition is expression then this expression must be implicitly convertible to System.IDisposable.

Local variables declared in a resource-acquisition are read-only, and must include an initializer. A compile-time error occurs if the embedded statement attempts to modify these local variables (via assignment or the ++ and ‑‑ operators), take the address of them, or pass them as ref or out parameters.

A using statement is translated into three parts: acquisition, usage, and disposal. Usage of the resource is implicitly enclosed in a try statement that includes a finally clause. This finally clause disposes of the resource. If a null resource is acquired, then no call to Dispose is made, and no exception is thrown. If the resource is of type dynamic it is dynamically converted through an implicit dynamic conversion (§6.1.8) to IDisposable during acquisition in order to ensure that the conversion is successful before the usage and disposal.

A using statement of the form

using (ResourceType resource = expression) statement

corresponds to one of three possible expansions. When ResourceType is a non-nullable value type, the expansion is

{
ResourceType resource = expression;
try {
statement;
}
finally {
((IDisposable)resource).Dispose();
}
}

Otherwise, when ResourceType is a nullable value type or a reference type other than dynamic, the expansion is

{
ResourceType resource = expression;
try {
statement;
}
finally {
if (resource!= null) ((IDisposable)resource).Dispose();
}
}

Otherwise, when ResourceType is dynamic, the expansion is

{
ResourceType resource = expression;
IDisposable d = (IDisposable)resource;
try {
statement;
}
finally {
if (d!= null) d.Dispose();
}
}

In either expansion, the resource variable is read-only in the embedded statement, and the d variable is inaccessible in, and invisible to, the embedded statement.

An implementation is permitted to implement a given using-statement differently, e.g. for performance reasons, as long as the behavior is consistent with the above expansion.

A using statement of the form

using (expression) statement

has the same three possible expansions. In this case ResourceType is implicitly the compile-time type of the expression, if it has one. Otherwise the interface IDisposable itself is used as the ResourceType. The resource variable is inaccessible in, and invisible to, the embedded statement.

When a resource-acquisition takes the form of a local-variable-declaration, it is possible to acquire multiple resources of a given type. A using statement of the form

using (ResourceType r1 = e1, r2 = e2,..., rN = eN) statement

is precisely equivalent to a sequence of nested using statements:

using (ResourceType r1 = e1)
using (ResourceType r2 = e2)
...
using (ResourceType rN = eN)
statement

The example below creates a file named log.txt and writes two lines of text to the file. The example then opens that same file for reading and copies the contained lines of text to the console.

using System;
using System.IO;

class Test
{
static void Main() {
using (TextWriter w = File.CreateText("log.txt")) {
w.WriteLine("This is line one");
w.WriteLine("This is line two");
}

using (TextReader r = File.OpenText("log.txt")) {
string s;
while ((s = r.ReadLine())!= null) {
Console.WriteLine(s);
}

}
}
}

Since the TextWriter and TextReader classes implement the IDisposable interface, the example can use using statements to ensure that the underlying file is properly closed following the write or read operations.

The yield statement

The yield statement is used in an iterator block (§8.2) to yield a value to the enumerator object (§10.14.4) or enumerable object (§10.14.5) of an iterator or to signal the end of the iteration.

yield-statement:
yield return expression;
yield break;

yield is not a reserved word; it has special meaning only when used immediately before a return or break keyword. In other contexts, yield can be used as an identifier.

There are several restrictions on where a yield statement can appear, as described in the following.

· It is a compile-time error for a yield statement (of either form) to appear outside a method-body, operator-body or accessor-body

· It is a compile-time error for a yield statement (of either form) to appear inside an anonymous function.

· It is a compile-time error for a yield statement (of either form) to appear in the finally clause of a try statement.

· It is a compile-time error for a yield return statement to appear anywhere in a try statement that contains any catch clauses.

The following example shows some valid and invalid uses of yield statements.

delegate IEnumerable<int> D();

IEnumerator<int> GetEnumerator() {
try {
yield return 1; // Ok
yield break; // Ok
}
finally {
yield return 2; // Error, yield in finally
yield break; // Error, yield in finally
}

try {
yield return 3; // Error, yield return in try...catch
yield break; // Ok
}
catch {
yield return 4; // Error, yield return in try...catch
yield break; // Ok
}

D d = delegate {
yield return 5; // Error, yield in an anonymous function
};
}

int MyMethod() {
yield return 1; // Error, wrong return type for an iterator block
}

An implicit conversion (§6.1) must exist from the type of the expression in the yield return statement to the yield type (§10.14.3) of the iterator.

A yield return statement is executed as follows:

· The expression given in the statement is evaluated, implicitly converted to the yield type, and assigned to the Current property of the enumerator object.

· Execution of the iterator block is suspended. If the yield return statement is within one or more try blocks, the associated finally blocks are not executed at this time.

· The MoveNext method of the enumerator object returns true to its caller, indicating that the enumerator object successfully advanced to the next item.

The next call to the enumerator object’s MoveNext method resumes execution of the iterator block from where it was last suspended.

A yield break statement is executed as follows:

· If the yield break statement is enclosed by one or more try blocks with associated finally blocks, control is initially transferred to the finally block of the innermost try statement. When and if control reaches the end point of a finally block, control is transferred to the finally block of the next enclosing try statement. This process is repeated until the finally blocks of all enclosing try statements have been executed.

· Control is returned to the caller of the iterator block. This is either the MoveNext method or Dispose method of the enumerator object.

Because a yield break statement unconditionally transfers control elsewhere, the end point of a yield break statement is never reachable.

Namespaces

C# programs are organized using namespaces. Namespaces are used both as an “internal” organization system for a program, and as an “external” organization system—a way of presenting program elements that are exposed to other programs.

Using directives (§9.4) are provided to facilitate the use of namespaces.

Compilation units

A compilation-unit defines the overall structure of a source file. A compilation unit consists of zero or more using-directives followed by zero or more global-attributes followed by zero or more namespace-member-declarations.

compilation-unit:
extern-alias-directives_opt using-directives_opt global-attributes_opt
namespace-member-declarations_opt

A C# program consists of one or more compilation units, each contained in a separate source file. When a C# program is compiled, all of the compilation units are processed together. Thus, compilation units can depend on each other, possibly in a circular fashion.

The using-directives of a compilation unit affect the global-attributes and namespace-member-declarations of that compilation unit, but have no effect on other compilation units.

The global-attributes (§17) of a compilation unit permit the specification of attributes for the target assembly and module. Assemblies and modules act as physical containers for types. An assembly may consist of several physically separate modules.

The namespace-member-declarations of each compilation unit of a program contribute members to a single declaration space called the global namespace. For example:

File A.cs:

class A {}

File B.cs:

class B {}

The two compilation units contribute to the single global namespace, in this case declaring two classes with the fully qualified names A and B. Because the two compilation units contribute to the same declaration space, it would have been an error if each contained a declaration of a member with the same name.

Namespace declarations

A namespace-declaration consists of the keyword namespace, followed by a namespace name and body, optionally followed by a semicolon.

namespace-declaration:
namespace qualified-identifier namespace-body;_opt

qualified-identifier:
identifier
qualified-identifier. identifier

namespace-body:
{ extern-alias-directives_opt using-directives_opt namespace-member-declarations_opt }

A namespace-declaration may occur as a top-level declaration in a compilation-unit or as a member declaration within another namespace-declaration. When a namespace-declaration occurs as a top-level declaration in a compilation-unit, the namespace becomes a member of the global namespace. When a namespace-declaration occurs within another namespace-declaration, the inner namespace becomes a member of the outer namespace. In either case, the name of a namespace must be unique within the containing namespace.

Namespaces are implicitly public and the declaration of a namespace cannot include any access modifiers.

Within a namespace-body, the optional using-directives import the names of other namespaces and types, allowing them to be referenced directly instead of through qualified names. The optional namespace-member-declarations contribute members to the declaration space of the namespace. Note that all using-directives must appear before any member declarations.

The qualified-identifier of a namespace-declaration may be a single identifier or a sequence of identifiers separated by “.” tokens. The latter form permits a program to define a nested namespace without lexically nesting several namespace declarations. For example,

namespace N1.N2
{
class A {}

class B {}
}

is semantically equivalent to

namespace N1
{
namespace N2
{
class A {}

class B {}
}
}

Namespaces are open-ended, and two namespace declarations with the same fully qualified name contribute to the same declaration space (§3.3). In the example

namespace N1.N2
{
class A {}
}

namespace N1.N2
{
class B {}
}

the two namespace declarations above contribute to the same declaration space, in this case declaring two classes with the fully qualified names N1.N2.A and N1.N2.B. Because the two declarations contribute to the same declaration space, it would have been an error if each contained a declaration of a member with the same name.

Extern aliases

An extern-alias-directive introduces an identifier that serves as an alias for a namespace. The specification of the aliased namespace is external to the source code of the program and applies also to nested namespaces of the aliased namespace.

extern-alias-directives:
extern-alias-directive
extern-alias-directives extern-alias-directive

extern-alias-directive:
extern alias identifier;

The scope of an extern-alias-directive extends over the using-directives, global-attributes and namespace-member-declarations of its immediately containing compilation unit or namespace body.

Within a compilation unit or namespace body that contains an extern-alias-directive, the identifier introduced by the extern-alias-directive can be used to reference the aliased namespace. It is a compile-time error for the identifier to be the word global.

An extern-alias-directive makes an alias available within a particular compilation unit or namespace body, but it does not contribute any new members to the underlying declaration space. In other words, an extern-alias-directive is not transitive, but, rather, affects only the compilation unit or namespace body in which it occurs.

The following program declares and uses two extern aliases, X and Y, each of which represent the root of a distinct namespace hierarchy:

extern alias X;
extern alias Y;

class Test
{
X::N.A a;
X::N.B b1;
Y::N.B b2;
Y::N.C c;
}

The program declares the existence of the extern aliases X and Y, but the actual definitions of the aliases are external to the program. The identically named N.B classes can now be referenced as X.N.B and Y.N.B, or, using the namespace alias qualifier, X::N.B and Y::N.B. An error occurs if a program declares an extern alias for which no external definition is provided.

Using directives

Using directives facilitate the use of namespaces and types defined in other namespaces. Using directives impact the name resolution process of namespace-or-type-names (§3.8) and simple-names (§7.6.2), but unlike declarations, using directives do not contribute new members to the underlying declaration spaces of the compilation units or namespaces within which they are used.

using-directives:
using-directive
using-directives using-directive

using-directive:
using-alias-directive
using-namespace-directive

A using-alias-directive (§9.4.1) introduces an alias for a namespace or type.

A using-namespace-directive (§9.4.2) imports the type members of a namespace.

The scope of a using-directive extends over the namespace-member-declarations of its immediately containing compilation unit or namespace body. The scope of a using-directive specifically does not include its peer using-directives. Thus, peer using-directives do not affect each other, and the order in which they are written is insignificant.

Using alias directives

A using-alias-directive introduces an identifier that serves as an alias for a namespace or type within the immediately enclosing compilation unit or namespace body.

using-alias-directive:
using identifier = namespace-or-type-name;

Within member declarations in a compilation unit or namespace body that contains a using-alias-directive, the identifier introduced by the using-alias-directive can be used to reference the given namespace or type. For example:

namespace N1.N2
{
class A {}
}

namespace N3
{
using A = N1.N2.A;

class B: A {}
}

Above, within member declarations in the N3 namespace, A is an alias for N1.N2.A, and thus class N3.B derives from class N1.N2.A. The same effect can be obtained by creating an alias R for N1.N2 and then referencing R.A:

namespace N3
{
using R = N1.N2;

class B: R.A {}
}

The identifier of a using-alias-directive must be unique within the declaration space of the compilation unit or namespace that immediately contains the using-alias-directive. For example:

namespace N3
{
class A {}
}

namespace N3
{
using A = N1.N2.A; // Error, A already exists
}

Above, N3 already contains a member A, so it is a compile-time error for a using-alias-directive to use that identifier. Likewise, it is a compile-time error for two or more using-alias-directives in the same compilation unit or namespace body to declare aliases by the same name.

A using-alias-directive makes an alias available within a particular compilation unit or namespace body, but it does not contribute any new members to the underlying declaration space. In other words, a using-alias-directive is not transitive but rather affects only the compilation unit or namespace body in which it occurs. In the example

namespace N3
{
using R = N1.N2;
}

namespace N3
{
class B: R.A {} // Error, R unknown
}

the scope of the using-alias-directive that introduces R only extends to member declarations in the namespace body in which it is contained, so R is unknown in the second namespace declaration. However, placing the using-alias-directive in the containing compilation unit causes the alias to become available within both namespace declarations:

using R = N1.N2;

namespace N3
{
class B: R.A {}
}

namespace N3
{
class C: R.A {}
}

Just like regular members, names introduced by using-alias-directives are hidden by similarly named members in nested scopes. In the example

using R = N1.N2;

namespace N3
{
class R {}

class B: R.A {} // Error, R has no member A
}

the reference to R.A in the declaration of B causes a compile-time error because R refers to N3.R, not N1.N2.

The order in which using-alias-directives are written has no significance, and resolution of the namespace-or-type-name referenced by a using-alias-directive is not affected by the using-alias-directive itself or by other using-directives in the immediately containing compilation unit or namespace body. In other words, the namespace-or-type-name of a using-alias-directive is resolved as if the immediately containing compilation unit or namespace body had no using-directives. A using-alias-directive may however be affected by extern-alias-directives in the immediately containing compilation unit or namespace body. In the example

namespace N1.N2 {}

namespace N3
{
extern alias E;

using R1 = E.N; // OK

using R2 = N1; // OK

using R3 = N1.N2; // OK

using R4 = R2.N2; // Error, R2 unknown
}

the last using-alias-directive results in a compile-time error because it is not affected by the first using-alias-directive. The first using-alias-directive does not result in an error since the scope of the extern alias E includes the using-alias-directive.

A using-alias-directive can create an alias for any namespace or type, including the namespace within which it appears and any namespace or type nested within that namespace.

Accessing a namespace or type through an alias yields exactly the same result as accessing that namespace or type through its declared name. For example, given

namespace N1.N2
{
class A {}
}

namespace N3
{
using R1 = N1;
using R2 = N1.N2;

class B
{
N1.N2.A a; // refers to N1.N2.A
R1.N2.A b; // refers to N1.N2.A
R2.A c; // refers to N1.N2.A
}
}

the names N1.N2.A, R1.N2.A, and R2.A are equivalent and all refer to the class whose fully qualified name is N1.N2.A.

Using aliases can name a closed constructed type, but cannot name an unbound generic type declaration without supplying type arguments. For example:

namespace N1
{
class A<T>
{
class B {}
}
}

namespace N2
{
using W = N1.A; // Error, cannot name unbound generic type

using X = N1.A.B; // Error, cannot name unbound generic type

using Y = N1.A<int>; // Ok, can name closed constructed type

using Z<T> = N1.A<T>; // Error, using alias cannot have type parameters
}

Using namespace directives

A using-namespace-directive imports the types contained in a namespace into the immediately enclosing compilation unit or namespace body, enabling the identifier of each type to be used without qualification.

using-namespace-directive:
using namespace-name;

Within member declarations in a compilation unit or namespace body that contains a using-namespace-directive, the types contained in the given namespace can be referenced directly. For example:

namespace N1.N2
{
class A {}
}

namespace N3
{
using N1.N2;

class B: A {}
}

Above, within member declarations in the N3 namespace, the type members of N1.N2 are directly available, and thus class N3.B derives from class N1.N2.A.

A using-namespace-directive imports the types contained in the given namespace, but specifically does not import nested namespaces. In the example

namespace N1.N2
{
class A {}
}

namespace N3
{
using N1;

class B: N2.A {} // Error, N2 unknown
}

the using-namespace-directive imports the types contained in N1, but not the namespaces nested in N1. Thus, the reference to N2.A in the declaration of B results in a compile-time error because no members named N2 are in scope.

Unlike a using-alias-directive, a using-namespace-directive may import types whose identifiers are already defined within the enclosing compilation unit or namespace body. In effect, names imported by a using-namespace-directive are hidden by similarly named members in the enclosing compilation unit or namespace body. For example:

namespace N1.N2
{
class A {}

class B {}
}

namespace N3
{
using N1.N2;

class A {}
}

Here, within member declarations in the N3 namespace, A refers to N3.A rather than N1.N2.A.

When more than one namespace imported by using-namespace-directives in the same compilation unit or namespace body contain types by the same name, references to that name are considered ambiguous. In the example

namespace N1
{
class A {}
}

namespace N2
{
class A {}
}

namespace N3
{
using N1;

using N2;

class B: A {} // Error, A is ambiguous
}

both N1 and N2 contain a member A, and because N3 imports both, referencing A in N3 is a compile-time error. In this situation, the conflict can be resolved either through qualification of references to A, or by introducing a using-alias-directive that picks a particular A. For example:

namespace N3
{
using N1;

using N2;

using A = N1.A;

class B: A {} // A means N1.A
}

Like a using-alias-directive, a using-namespace-directive does not contribute any new members to the underlying declaration space of the compilation unit or namespace, but rather affects only the compilation unit or namespace body in which it appears.

The namespace-name referenced by a using-namespace-directive is resolved in the same way as the namespace-or-type-name referenced by a using-alias-directive. Thus, using-namespace-directives in the same compilation unit or namespace body do not affect each other and can be written in any order.

Namespace members

A namespace-member-declaration is either a namespace-declaration (§9.2) or a type-declaration (§9.6).

namespace-member-declarations:
namespace-member-declaration
namespace-member-declarations namespace-member-declaration

namespace-member-declaration:
namespace-declaration
type-declaration

A compilation unit or a namespace body can contain namespace-member-declarations, and such declarations contribute new members to the underlying declaration space of the containing compilation unit or namespace body.

Type declarations

A type-declaration is a class-declaration (§10.1), a struct-declaration (§11.1), an interface-declaration (§13.1), an enum-declaration (§14.1), or a delegate-declaration (§15.1).

type-declaration:
class-declaration
struct-declaration
interface-declaration
enum-declaration
delegate-declaration

A type-declaration can occur as a top-level declaration in a compilation unit or as a member declaration within a namespace, class, or struct.

When a type declaration for a type T occurs as a top-level declaration in a compilation unit, the fully qualified name of the newly declared type is simply T. When a type declaration for a type T occurs within a namespace, class, or struct, the fully qualified name of the newly declared type is N.T, where N is the fully qualified name of the containing namespace, class, or struct.

A type declared within a class or struct is called a nested type (§10.3.8).

The permitted access modifiers and the default access for a type declaration depend on the context in which the declaration takes place (§3.5.1):

· Types declared in compilation units or namespaces can have public or internal access. The default is internal access.

· Types declared in classes can have public, protected internal, protected, internal, or private access. The default is private access.

· Types declared in structs can have public, internal, or private access. The default is private access.

Namespace alias qualifiers

The namespace alias qualifier:: makes it possible to guarantee that type name lookups are unaffected by the introduction of new types and members. The namespace alias qualifier always appears between two identifiers referred to as the left-hand and right-hand identifiers. Unlike the regular. qualifier, the left-hand identifier of the:: qualifier is looked up only as an extern or using alias.

A qualified-alias-member is defined as follows:

qualified-alias-member:
identifier:: identifier type-argument-list_opt

A qualified-alias-member can be used as a namespace-or-type-name (§3.8) or as the left operand in a member-access (§7.6.4).

A qualified-alias-member has one of two forms:

· N::I<A₁,..., A_K>, where N and I represent identifiers, and <A₁,..., A_K> is a type argument list. (K is always at least one.)

· N::I, where N and I represent identifiers. (In this case, K is considered to be zero.)

Using this notation, the meaning of a qualified-alias-member is determined as follows:

· If N is the identifier global, then the global namespace is searched for I:

o If the global namespace contains a namespace named I and K is zero, then the qualified-alias-member refers to that namespace.

o Otherwise, if the global namespace contains a non-generic type named I and K is zero, then the qualified-alias-member refers to that type.

o Otherwise, if the global namespace contains a type named I that has K type parameters, then the qualified-alias-member refers to that type constructed with the given type arguments.

o Otherwise, the qualified-alias-member is undefined and a compile-time error occurs.

· Otherwise, starting with the namespace declaration (§9.2) immediately containing the qualified-alias-member (if any), continuing with each enclosing namespace declaration (if any), and ending with the compilation unit containing the qualified-alias-member, the following steps are evaluated until an entity is located:

o If the namespace declaration or compilation unit contains a using-alias-directive that associates N with a type, then the qualified-alias-member is undefined and a compile-time error occurs.

o Otherwise, if the namespace declaration or compilation unit contains an extern-alias-directive or using-alias-directive that associates N with a namespace, then:

· If the namespace associated with N contains a namespace named I and K is zero, then the qualified-alias-member refers to that namespace.

· Otherwise, if the namespace associated with N contains a non-generic type named I and K is zero, then the qualified-alias-member refers to that type.

· Otherwise, if the namespace associated with N contains a type named I that has K type parameters, then the qualified-alias-member refers to that type constructed with the given type arguments.

· Otherwise, the qualified-alias-member is undefined and a compile-time error occurs.

· Otherwise, the qualified-alias-member is undefined and a compile-time error occurs.

Note that using the namespace alias qualifier with an alias that references a type causes a compile-time error. Also note that if the identifier N is global, then lookup is performed in the global namespace, even if there is a using alias associating global with a type or namespace.

Uniqueness of aliases

Each compilation unit and namespace body has a separate declaration space for extern aliases and using aliases. Thus, while the name of an extern alias or using alias must be unique within the set of extern aliases and using aliases declared in the immediately containing compilation unit or namespace body, an alias is permitted to have the same name as a type or namespace as long as it is used only with the:: qualifier.

In the example

namespace N
{
public class A {}

public class B {}
}

namespace N
{
using A = System.IO;

class X
{
A.Stream s1; // Error, A is ambiguous

A::Stream s2; // Ok
}
}

the name A has two possible meanings in the second namespace body because both the class A and the using alias A are in scope. For this reason, use of A in the qualified name A.Stream is ambiguous and causes a compile-time error to occur. However, use of A with the:: qualifier is not an error because A is looked up only as a namespace alias.

Classes

A class is a data structure that may contain data members (constants and fields), function members (methods, properties, events, indexers, operators, instance constructors, destructors and static constructors), and nested types. Class types support inheritance, a mechanism whereby a derived class can extend and specialize a base class.

Class declarations

A class-declaration is a type-declaration (§9.6) that declares a new class.

class-declaration:
attributes_opt class-modifiers_opt partial_opt class identifier type-parameter-list_opt
class-base_opt type-parameter-constraints-clauses_opt class-body;_opt

A class-declaration consists of an optional set of attributes (§17), followed by an optional set of class-modifiers (§10.1.1), followed by an optional partial modifier, followed by the keyword class and an identifier that names the class, followed by an optional type-parameter-list (§10.1.3), followed by an optional class-base specification (§10.1.4), followed by an optional set of type-parameter-constraints-clauses (§10.1.5), followed by a class-body (§10.1.6), optionally followed by a semicolon.

A class declaration cannot supply type-parameter-constraints-clauses unless it also supplies a type-parameter-list.

A class declaration that supplies a type-parameter-list is a generic class declaration. Additionally, any class nested inside a generic class declaration or a generic struct declaration is itself a generic class declaration, since type parameters for the containing type must be supplied to create a constructed type.

Class modifiers

A class-declaration may optionally include a sequence of class modifiers:

class-modifiers:
class-modifier
class-modifiers class-modifier

class-modifier:
new
public
protected
internal
private
abstract
sealed
static

It is a compile-time error for the same modifier to appear multiple times in a class declaration.

The new modifier is permitted on nested classes. It specifies that the class hides an inherited member by the same name, as described in §10.3.4. It is a compile-time error for the new modifier to appear on a class declaration that is not a nested class declaration.

The public, protected, internal, and private modifiers control the accessibility of the class. Depending on the context in which the class declaration occurs, some of these modifiers may not be permitted (§3.5.1).

The abstract, sealed and static modifiers are discussed in the following sections.

Abstract classes

The abstract modifier is used to indicate that a class is incomplete and that it is intended to be used only as a base class. An abstract class differs from a non-abstract class in the following ways:

· An abstract class cannot be instantiated directly, and it is a compile-time error to use the new operator on an abstract class. While it is possible to have variables and values whose compile-time types are abstract, such variables and values will necessarily either be null or contain references to instances of non-abstract classes derived from the abstract types.

· An abstract class is permitted (but not required) to contain abstract members.

· An abstract class cannot be sealed.

When a non-abstract class is derived from an abstract class, the non-abstract class must include actual implementations of all inherited abstract members, thereby overriding those abstract members. In the example

abstract class A
{
public abstract void F();
}

abstract class B: A
{
public void G() {}
}

class C: B
{
public override void F() {
// actual implementation of F
}
}

the abstract class A introduces an abstract method F. Class B introduces an additional method G, but since it doesn’t provide an implementation of F, B must also be declared abstract. Class C overrides F and provides an actual implementation. Since there are no abstract members in C, C is permitted (but not required) to be non-abstract.

Sealed classes

The sealed modifier is used to prevent derivation from a class. A compile-time error occurs if a sealed class is specified as the base class of another class.

A sealed class cannot also be an abstract class.

The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.

Static classes

The static modifier is used to mark the class being declared as a static class.A static class cannot be instantiated, cannot be used as a type and can contain only static members. Only a static class can contain declarations of extension methods (§10.6.9).

A static class declaration is subject to the following restrictions:

· A static class may not include a sealed or abstract modifier. Note, however, that since a static class cannot be instantiated or derived from, it behaves as if it was both sealed and abstract.

· A static class may not include a class-base specification (§10.1.4) and cannot explicitly specify a base class or a list of implemented interfaces. A static class implicitly inherits from type object.

· A static class can only contain static members (§10.3.7). Note that constants and nested types are classified as static members.

· A static class cannot have members with protected or protected internal declared accessibility.

It is a compile-time error to violate any of these restrictions.

A static class has no instance constructors. It is not possible to declare an instance constructor in a static class, and no default instance constructor (§10.11.4) is provided for a static class.

The members of a static class are not automatically static, and the member declarations must explicitly include a static modifier (except for constants and nested types). When a class is nested within a static outer class, the nested class is not a static class unless it explicitly includes a static modifier.