Click here to Skip to main content
15,889,281 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
After reading https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ despite the document listing a list of Reserved keywords and a list of Contextual keywords, as well stating how any new keyword added to the C# language will be a contextual keyword... it mentions only "one" difference between Reserved Keywords and Contextual keywords in C#.

Being that a Reserved keyword (e.g. `namespace`, `class`, `int`, `static`, `using`, etc..) cannot be used as an identifier (e.g. namespace identifier, type identifier, type member identifier, etc..) unless it is prefixed with `@`. For example:

namespace @namespace
{
    public class @class
    {
        public int @int = 4;
    }
}


While a Contextual keyword (e.g. `global`, `add`, `var`, `await` etc...) can be used as an identifier (e.g. namespace identifier, type identifier, type member identifier, etc..) without the need to utilize any special character, before a contextual keyword, to do so. For example:

namespace global
{
    public class add
    {
        public int var = 4;
    }
}



Is that really the only difference between a Reserved keyword and a Contextual keyword in C#? Perhaps there is more to it than that in terms of why the above rule exists?

What I have tried:

C# language question concerning C# keywords (reserved and contextual). There is no specific online resource that answer the above question.
Posted
Updated 17-Oct-21 0:07am

Quote:
Is that really the only difference between a Reserved keyword and a Contextual keyword in C#?

Yes.

Basically, it's a legacy thing: the reserved keywords are the original language keywords, and cannot be used as identifier just as they can't in other languages.

Contextual keywords were added later (when Linq was added with .NET 3.5 for example) and if they were added as reserved keywords that would be a breaking change - it would be necessary to make substantial changes to some existing code in order to compile it with the later compiler.
 
Share this answer
 
Comments
TomLeywin 17-Oct-21 23:40pm    
Hi, I also posted this question on a different site and one user mentioned the following:

A reserved keyword has meaning to the compiler IN EVERY/ANY programming context it is used in. Which is why if you use a reserved keyword incorrectly such as an identifier of a variable, a compile time error will be generated. Unless it is prefixed with @.

A contextual keyword has meaning to the compiler ONLY IN SPECIFIC programming contexts it is used in. Which is why if you use a contextual keyword incorrectly, such as an identifier of a variable, a compile time error will NOT be generated. Because in that programming context it is not considered a keyword (does not have meaning to the compiler).

Any thoughts to the above? It's "sounds" true but i just don't know.
I like to think of reserved words as sacred cows, and contextual keywords as ordinary livestock :) imho, all cows should be sacred (no reference to Hinduism intended).

Isn't the idea of unique names (without multiple meanings in different contexts) essential to strongly typed languages ?

OriginalGriff: "if they (new keywords) were added as reserved keywords that would be a breaking change."

a slightly different spin on that::

... if the language designers don't give a damn about creating confusion, semantic incompatibility, and breaking existing code ... then adding new keywords that are not reserved is an issue that goes away.

... Mr. Occam says: make new keywords reserved, and make their names so distinctive that they present virtually no danger of being duplicates of widely used names.

@namespace == abomination !
 
Share this answer
 
Comments
TomLeywin 17-Oct-21 14:19pm    
Hi, I also posted this question on a different site and one user mentioned the following:

A reserved keyword has meaning to the compiler in every/any programming context it is used in. Which is why if you use a reserved keyword incorrectly such as an identifier of a variable, a compile time error will be generated. Unless it is prefixed with @.

A contextual keyword has meaning to the compiler only in specific programming contexts it is used in. Which is why if you use a contextual keyword incorrectly, such as an identifier of a variable, a compile time error will NOT be generated. Because in that programming context it is not considered a keyword (does not have meaning to the compiler).

Is all what the above says true?
BillWoodruff 17-Oct-21 15:22pm    
Hi Tom, i can't react meaningfully to a conversation i'm not a party to :)

My opinions here are deliberately expressed "provocatively."

i prefer a language with very strict strong-typing: is that bias, or preference, habit, or wisdom learned from experience ?

Perhaps you'd enjoy my rant/story about a recent semantic clash i found:

https://www.codeproject.com/Messages/5829757/A-conversation-heard-at-Microsoft
TomLeywin 17-Oct-21 15:31pm    
I guess what I'm asking is what your opinion on what that other user said... What I do know is that he too is a beginner like me.

It's site with private rooms where we (biginners) pretty much share our thoughts on certain matters.

This is one we were talking about and he came up with that notion between reserved keywords and contextual keywords. But we are unsure what is the real answer.
BillWoodruff 17-Oct-21 15:33pm    
"I guess what I'm asking is what your opinion on what that other user said."

as i said, i can't react meaningfully to a conversation i'm not a party to :)
TomLeywin 17-Oct-21 16:04pm    
That's ok. I just thought i'd try to get a second opinion on what that other user said.

It's something we, on that other site, are debating on. I hope OrginalGriff can help me out with that :)

But if you change mind and would like to give your opinion on that please feel free to. Thanks

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900