Is my understanding (if not my explanation) correct for the most part?
I do not agree in one point:
A literal is some kind of compile time constant (as "Hello World", 5 or 'A'). However, there are no "Literal-Types"; the literal always is the actual value.
Primitive types are IMO "basic" types like string, int, double, float, short, ...
So primitive have their types of literals connected with them.
I guess one thing you did not mention is space and allocation. Primitives are value types and are allocated on the stack (as long as they are not associated with an object) except for the string type as you mentioned (the string class allocates its space on the heap).
Although objects themselves contain primitives there storage resides where the actual object is allocated, which is on the heap.
Other then that your statement is pretty well written. Do you have a specific question that I missed :)?
Don't forget there also exists the ASP.Net Literal class.
EDIT: Thus, an answer to the question in the title is no, as there isn't a "Primitive" class that provides the same functionality. This can be viewed as a bit of a smart alec response, though.
Yes, a literal is a value expressed in source code - so while VB supports date/time and XML literals, C# doesn't.
From the C# spec, section 2.4.4:
A literal is a source code representation of a value.
As you say, this is unrelated to value type vs reference type - string is indeed a reference type.
One literal which no-one has mentioned yet it null by the way...
It's also unrelated to primitive types - from Type.IsPrimitive:
The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Double, and Single.
... the C# specification doesn't actually define the idea of a "primitive" type, but note that String isn't in the list above.
In terms of literals being compile-time constants... in C# every literal has a representation which can be baked directly into the assembly; the extra literals in VB mean they're not constants as the CLR would understand them - you can't have a const DateTime for example - but they're still literals.
I think that your understanding is mostly correct. As winSharp93 said, literals are values which themselves have types, but there's no such thing as a "literal type". That is, while you can have string literals, strings are not a "literal type". As you have guessed, what defines a literal is that the value is directly written down in source code, although your requirement that no type needs to be specified seems overly strict (e.g. F# has array literals, and can infer the type of the array literal [| 1; 2; 3 |], but cannot necessarily infer the type of the empty array literal [| |]).
Unfortunately, I don't think that there is a well-agreed-upon definition of what makes a primitive. Certainly, as Jon Skeet points out, the CLR has its own definition of primitiveness (Type.IsPrimitive), which rules out strings. However, other reputable sources consider string and even object to be primitive types within C#. I prefer this definition, since there is built-in support in C# for strings, such as the use of the + operator for concatenation and the use of == as value equality rather than reference equality, as well as the fact that the string type can be referred to using the short form string rather than having to use the full name System.String.
Here is an MSDN page, talking about the CLS, that includes string as a primitive type:
The .NET Framework class library includes types that correspond to the primitive data types that compilers use. Of these types, the following are CLS-compliant: Byte, Int16, Int32, Int64, Single, Double, Boolean, Char, Decimal, IntPtr, and String. For more information about these types, see the table of types in .NET Framework Class Library Overview.
I just wanted to inject a quick note here.
The C# language specification clearly defines "literal" -- a literal is a source code representation of a value. Literals are things like true, 10, 5.7, 'c', "hello" and null -- they are text that represents a specific value.
The C# language specification uses the word "primitive" twice; it is never defined and completely vague as to what it could possibly mean.
The C# language spec has no need to use or define the word "primitive" and therefore should not make use of this vague term. I've had a talk with Mads and we've agreed that future editions of the spec will be reworded to eliminate this usage completely.
How other type systems specifications -- the reflection library, the CLI, the VES, and so on -- define the word "primitive" is of course up to them.
Thanks for bringing up the question.