Excerpt from Eric Lippert's Blog about What the meaning of "is", is:
A common conception of types is that a type is a set [...] of values, and that assignment compatibility is merely checking to see if a given value is a member of the necessary set. But that’s not the case in C#.
The counter example he gives is that null is string
returns false
, but string b = null
is totally fine by the C# compiler.
Perhaps this is a silly question, but what is a better way to define the idea of "type" in a C#.Net context? Is it just a word used to define ... memory footprint rules? ... to the CLR? I realize how loose (and horribly wrong) that definition is, but I'm struggling to fit a nice wrapper and bow around the idea of type.
Note: the simpler, yet completely accurate, the better. (strong N type, here).
what is a better way to define the idea of "type" in a C#.Net context? Is it just a word used to define ... memory footprint rules? I'm struggling to fit a nice wrapper and bow around the idea of type.
This is a tricky problem. You opened with a link to my article about is
, but I think the one you really want to read is this one:
http://blogs.msdn.com/b/ericlippert/archive/2011/08/29/what-is-this-thing-you-call-a-quot-type-quot-part-one.aspx
http://blogs.msdn.com/b/ericlippert/archive/2011/09/07/what-is-this-thing-you-call-a-quot-type-quot-part-two.aspx
Briefly:
From a "mathematical" point of view, a type is like a number: an abstract quantity that we can manipulate using rules. Like "if T
is a type then T[]
is also a type", and so on.
Once we have an abstract notion of type then we can assign every expression a type, and then we can make a verifier that automatically determines whether a program follows the type safety rules or not.
The traditional English definition of Type
is a good place to start.
a category of people or things having common characteristics.
a .NET Type defines a specific category of .NET object (i.e.: System.IO.Stream). It contains a set of properties and methods (characteristics) of a particular sort of .NET object.
Are you looking for a more technical description (i.e.: memory management, etc)?
There are some good answers to a similar question here:
Why does the is operator return false when given null?
A more elaborate discussion of the null literal is here:
What is the type of null literal?
It seems that there used to be a null type in earlier versions of .NET for symbolic purposes, but was subsequently dropped in subsequent versions.
From an IL programmer's perspective, I can say that when a statement like 'if(myvar == null)' is written in IL, it would go something like this:
Ldloc myvar
brfalse IfNullLabel
The variable is checked for a null reference with just one IL instruction, regardless of its type. If this was compared to another string, then the Equals method would be called. So internally, a value is null when its reference is pointing to the null literal. As simple as that.
I think you might be over thinking this one a bit.. according to the Programming Guide
The information stored in a type can include the following:
- The storage space that a variable of the type requires.
- The maximum and minimum values that it can represent.
- The members (methods, fields, events, and so on) that it contains.
- The base type it inherits from.
- The location where the memory for variables will be allocated at run time.
- The kinds of operations that are permitted.
I know that doesn't account for null
but in c# null
is really just lack of a referenced memory address.
Having a little more context would help in answering your question ("[...] define the idea of 'type' in a C#.Net context[...]
"), but here's a quick stab at it. The concept of a type in .NET comes from object-oriented programming, and is a generalization of the datatype concept from pre-OOP programming languages. In its simplest form, you could say that...
A type is a named template for a
structure, instances of which hold data and/or behavior.
Answers to questions in EDIT section:
[...] how does the CLR treat the idea of a type?
I don't know exactly what you mean by that, but a type in the CLR - the 'named template' in my definition above - is physically stored as CIL and is represented in the system by an object which itself (like all objects) is of a type.
In this case, that type is named, sure enough, System.Type
. (In case you're curious, this type is physically stored in the mscorlib
assembly.) I know that I'm using a term in its own definition, but it's hard not to, since the concept is inherently recursive.
[...] does the CLR need to implicitly cast null to a string in the
assignment string s = null? Answers so far imply no, it does not, but
what allows that assignment? Is null just treated as a special case
here?
Yes, it is a special case and no, neither the compiler nor the CLR cast null
to a string
(or anything else). null
has no type (1) and cannot be converted to any type -- it is a special "value" that denotes the absence of a value (2) and is thus assignable to a variable of any reference type (3).
(1) Depending on where you look, it may or may not be of type "null type".
(2) Such a value would be a reference to an instance of that type.
(3) There are two kinds of types -- reference types and value types -- and null
truly only applies to the former kind. It can appear in source code (e.g. int? i = null;
) as being assigned to a variable of a nullable value type, but that's just syntactic sugar and what happens behind the scenes is very different and only tangentially related to this discussion.