Why is there no "date" shorthand of System.DateTime in C#?

Question

Such as int, long, ushort, uint, short, etc.

Why isn't there a short hand for System.DateTime?

Answer 1

Many types are associated with "shorthand" keywords in C#; for example, System.Int32 can also be written int and System.String can be written string. Why isn't there a shorthand for System.DateTime?

Before I answer that question -- or rather, fail to answer it -- let's first note the types that have shorthands in C#. They are

object 
string 
sbyte byte short ushort int uint long ulong 
char 
bool 
decimal double float

Let me first address some of the other answers.

Mystere Man notes correctly that several of these keywords come from C; C has int and the rather wordy unsigned int, double, and a few others. However C most notably does not have bool, long, decimal, object or string.

I think we can reasonably say that one justification for including keywords int and char and so on is so that users familiar with C and C++ can be productive quickly in C#. The aim here is for the keywords to be familiar to C programmers, but it was absolutely not the aim for these keywords to have the same semantics as they do in C. C does not specify the size of any of those, for example, and strongly encourages int to be the "natural size" of the machine. C# does specify the exact size and range of each type.

So I do not think we can reasonably say that the justification for not having a shorthand for System.DateTime is because there was none in C. There was no string or decimal in C either.

Jason notes that DateTime is not "part of the C# language" and therefore does not have a keyword. But that is thoroughly begging the question! The question is essentially then "OK, so then why is DateTime not a part of the C# language?" Answering a question in a manner which requires a question of equal difficulty to be answered is called "begging the question", and this question has been thoroughly begged.

It is instructive to consider what are the "fundamental" types. All of the types that have keywords in C# are "very special" in some way, except for decimal. That is, the underlying runtime has special behaviour built into it for object, obviously, as it is the universal base type. string could have simply been an array of char, but it is not; strings are special. (Because they can be interned, they can be constant, they can exist in metadata, and so on.) The integral and binary floating point types all have special handling built into the framework for their operations.

But System.Decimal is just another struct type; it's 128 bits of integers and a whole lot of user-defined operators. Anyone could implement their own decimal arithmetic type if they wanted to. But "blessing" System.Decimal by making it a part of the C# language means that even though its conversions are implemented as methods, we treat them as built in conversions, not as user-defined conversions.

So decimal really is an odd one. It is not a "fundamental" type of the runtime, but it is a keyword.

This brings up an interesting point though. System.IntPtr and System.UIntPtr *are* fundamental types of the runtime. They are the "pointer sized integer" types; they are what C means by int and unsigned int. Even though these types are fundamental to the .NET runtime's type system, they do not get blessed with a keyword.

Thus, we can reject the argument that only "fundamental" types get a keyword. There is a non-fundamental type that got a keyword, and a fundamental type that did not get a keyword, so there is no one-to-one relationship between fundamental types and types that got a keyword.

Tigran opines that the choices were "historical", which is correct but does not actually answer the question.

Hans Passant notes correctly that clearly specifying the size and range of an int helps make the language behaviour consistent even as the native integer size changes, and notes that DateTime has already been designed to be "future proof". Though this analysis is correct, it does not explain why decimal is made a keyword. There's no fear that the "native decimal size" of a machine is going to change in the future. Moreover, the C# language already notes that though a double will always consume 8 bytes of storage, there is no requirement that C# restrict the processing of doubles to a mere 64 bits of precision; in fact C# programs often do double arithmetic in 80 or more bits of precision.

I don't think any of these answers successfully address the question. So let's return to the question:

Many types are associated with "shorthand" keywords in C#; for example, System.Int32 can also be written int and System.String can be written string. Why isn't there a shorthand for System.DateTime?

The answer to this question is the same as the answer to every question of the form "why does C# not implement a feature I like?" The answer is: we are not required to provide a justification for not implementing a feature. Features are expensive, and, as Raymond Chen often points out, are unimplemented by default. It takes no work to leave an unimplemented feature unimplemented.

The feature suggestion is not unreasonable at all; Visual Basic in some sense treats DateTime as a special type, and C# could too if we decided that it was worthwhile doing that work. But not every reasonable feature gets implemented.