Generally, names are not unique. Names are collected into groupings called scopes. Within a scope, a name may refer to multiple entities as long as they are of different kinds or have different signatures. In the VOS, the following kinds exist: methods, fields, nested types, properties, and events.
CLS Rule 4: All names introduced in a scope shall be distinct independent of kind. That is, while the VOS allows a single type to use the same name for a method and a field, the CLS does not.
CLS Rule 5: Fields and nested types must be distinct by identifier comparison alone, even though the VOS allows distinct signatures to be distinguished. Methods, properties, and events that have the same name (by identifier comparison) must differ by more than just the return type (although there is a special exception discussed in Conversion Operators).
CLS (consumers): need not consume types that violate these rules after ignoring any members that are marked as not CLS-compliant.
CLS (extenders): need not provide syntax for defining types that violate these rules.
CLS (frameworks): must not mark types as CLS-compliant if they violate these rules unless they mark sufficient offending items within the type as not CLS-compliant so that the remaining members do not conflict with one another.
A named entity has its name in exactly one scope. Hence, to identify a named entity, both a scope and a name need to be supplied. The scope is said to qualify the name. Types provide a scope for the names in the type; hence types qualify the names in the type. For example, consider a compound type Point
which has a field named x
. The name “field x”
by itself does not uniquely identify the named field, but the qualified name “field x
in type Point”
does.
Since types are named, the names of types are also grouped into scopes. To fully identify a type, the type name must be qualified by the scope that includes the type name. Type names are scoped by the assembly that contains the implementation of the type. An assembly is a configured set of loadable code modules and other resources that together implement a unit of functionality. The type name is said to be in the assembly scope of the assembly that implements the type. Assemblies themselves have names that form the basis of the VOS naming hierarchy; see the Assemblies specification.
The type definition:
The VOS supports two kinds of type alias:
Note: In V1, the underlying type must be a built-in integer type. They must be derived from System.Enum , hence they are value types. Like all value types, they must be sealed.
CLS Rule 6: The underlying type of an enum must be a built-in CLS integer type.
CLS Rule 7: There are two distinct kinds of enums, indicated by the presence or absence of the System.FlagsAttribute custom attribute. One represents named integer values, the other named bit flags that can be combined together to generate an unnamed value. While languages are encouraged to distinguish these, they need not do so.
CLS Rule 8: Literal static fields of an enum must have the type of the enum itself.
CLS (consumer): Must accept definition of enums that follow these rules, but need not distinguish flags from named values.
CLS (extender): Must provide syntax for defining enums that follow these rules, including allowing users to indicate for each enum type whether it is a flag or a named value, even though the language need not enforce the distinction.
CLS (frameworks): must not expose enums that violate these rules, and must not assume that enums have only the specified values (even for enums that are named values).
Note: type indistinct aliases are not supported in V1.