C# 'dynamic' keyword... is it really a RESERVED keyword or just a identifier that means something special when used as type?

Question

I have a C# 4.0 parser. It accepts 'dynamic' as a keyword as a type. My parser trips over statements found in working C# 3.0 programs of the form of:

dynamic = <exp> ;

So, it dynamic really a keyword? Or can it still be used as an arbitrary identifier name? (If so, why isn't 'int' treated the same way)?

Is there a reference spec somewhere that states whether dynamic is keyword? The latest ECMA C# 4 specification doesn't even mention 'dynamic', and the best I can find at the MS site is a "preliminary specification" which says its a keyword but I suspect that's just sloppy writing.

Answer 1

It's a keyword. (see edit below) I'm a little confused on what you mean by "why isn't 'int' treated the same way?"

You can't do this: int int = 5;

But you can do this, although it's not good practice: int @int = 5;

The C# 4.0 spec does mention dynamic in section 20.1.

EDIT: more info...

Using dynamic as a variable name is allowed, so it's not a keyword (but it is a contextual keyword - see Sean Devlin's post). See the screenshot below using .NET 4.0 beta

Check out Chris Burrow's blog post. An interesting quote from the post:

As you can see, the publicly visible members that use the type dynamic actually, behind the scenes, use the type object when they are emitted. There is no framework type "dynamic." However, those "objects" are all decorated in such a way that the compiler (or anyone else) can tell that they are meant to be handled dynamically.

Answer 2

dynamic is a contextual keyword as of C# 4.0. The fourth edition of the ECMA C# spec does not refer to C# 4.0. (Note the 2006 publication date.)

MSDN describes it as a keyword.

It's also in this table of contextual keywords. (Scroll down.)

Answer 3

It's not a "normal" keyword like if, for etc.

It's a contextual keyword like yield, from etc.

In particular, this compiles:

object dynamic = 0; // dynamic is a contextual keyword

but this doesn't:

object string = 0; // string is a regular keyword

You'd have to "escape" string like this:

object @string = 0;

This makes a lot of sense in terms of backward compatibility: it's unlikely that many people will have created a type called dynamic (which would cause ambiguity; IIRC the "real" type wins in this case) whereas it's very likely that existing code uses variables called dynamic.

In some ways it doesn't even need to be a contextual keyword (and I don't believe the specification ever explicitly refers to it as such) - you can think of it as the name of a type which is always available (like string and object). I would imagine that string etc were made keywords from v1 to avoid confusion, but adding genuine keywords (which can't be used as identifiers) would have a high compatibility cost now.