C# Language Design Notes for July 9, 2014
Notes are archived
- Detailed design of nameof <details settled>
- Design of #pragma warning extensions <allow identifiers>
Details of nameof
The overall design of
was decided in the design meeting on
Oct 7, 2013
. However, a number of issues weren’t addressed at the time.
The use of
as an expression can be ambiguous, as it looks like an invocation. In order to stay compatible, if there’s an invokable
in scope we’ll treat it as an invocation, regardless of whether that invocation is valid. This means that in those cases there is no way to apply the nameof operator. The recommendation of course will be to get rid of any use of
as an identifier, and we should think about having diagnostics helping with that.
Which operands are allowed?
The symbols recognized in a nameof expression must represent locals, range variables, parameters, type parameters, members, types or namespaces. Labels and preprocessor symbols are not allowed in a nameof expression.
In general, free-standing identifiers are looked up like simple names, and dotted rightmost identifiers are looked up like member access. It is thus an error to reference locals before their declaration, or to reference inaccessible members. However, there
are some exceptions:
All members are treated as if they were static members.
This means that instance members are accessed by dotting off the type rather than an instance expression. It also means that the accessibility rules around protected instance members are the simpler
rules that apply to static members.
Generic types are recognized by name only.
Normally there needs to be a type parameter list (or at least dimension specifier) to disambiguate, but type parameter lists or dimension specifiers are not needed, and in fact not allowed, on the rightmost
identifier in a nameof.
Ambiguities are not an error.
Even if multiple entities with the same name are found, nameof will succeed. For instance, if a property named
is inherited through one interface and a method named
is inherited through another, the usual ambiguity error will not occur.
The referenced set
Because ambiguities are allowed, a nameof operator can reference a set of different entities at the same time. The precise set of referenced entities in the presence of ambiguity can be loosely defined as “those it would be ambiguous between”. Thus, shadowed
members or other entities that wouldn’t normally be found by lookup, e.g. because they are in a base class or an enclosing scope of where an entity is found, will not be part of the referenced set.
The notion of referenced set has little importance for the language-level semantics, but is important for the tooling experience, e.g. for refactorings, go-to-definition, etc.
Reference to some entities, e.g. obsolete members,
’ methods, is normally an error. However, it is not an error in
members of the referenced set would give an error. If all non-error references give warnings, then a warning is given.
The resulting string
C# doesn’t actually have a notion of canonical name. Instead, equality between names is currently defined directly
names that may contain special symbols.
we want the resulting string to be the identifier
given, except that formatting characters are omitted, and Unicode escapes are resolved. Also, any leading
In the case of aliases, this means that those are not resolved to their underlying meaning: the identifier is that of the alias itself.
As a result, the meaning of the identifier is always only used to check if it is valid, never to decide what the resulting string is. There is no semantic component to determining the result of a nameof operator, only to determining if it is allowed.
Pragma warning directives
Now that custom diagnostics are on their way, we want to allow users to turn these on and off from source code, just as we do with the compiler’s own diagnostics today. To allow this, we need to extend the model of how a diagnostic is identified: today a number
is used, but that is not a scalable model when multiple diagnostic providers are involved.
Instead the design is that diagnostics are identified by an identifier. For compatibility the C# compiler’s own diagnostics can still be referenced with a number, but can also be referred to with the pattern
#pragma warning disable AsyncCoreSet
#pragma warning disable CS1234