C# Nullable types

[Jon Skeet [C# MVP]]

Well, it's a bit more complicated than that. If it's a parameter, for
example, the compiler doesn't complain at all. Example:

public boo StringIsNull(string s)
{
return (s == null);

}

Yes, s is definitely assigned, according to the spec:

<quote>
The following categories of variables are classified as initially
assigned:
[...]
* 6 Value parameters.
</quote>

In the above, s is a value parameter. So it is definitely assigned,
regardless of its value.

An "out" parameter, however, *isn't* definitely assigned at the start
of the method, so it would fail to compile - the variable would not
have a value which could be retrieved under the rules of the language.

Also, note that I said "Null is not a value technically speaking." I
qualified my remark because it depends on what is meant by the term "value."
Of course, null must be represented by a "value" in memory, but it
represents the absence of a value.

No, it represents the absence of an *instance* that value refers to.

And as you pointed out, if a member is
declared and not initialized, it is "initialized" as null. But that holds
true for value types as well as reference types. So, what we're seeing here
is more a decision on the part of the designers of the compiler, rather than
a "physical" reality.

I'm talking on the language level more than anything else - where null
is clearly defined to be a value which doesn't refer to any instance.

They could just as easily have assumed a null value
for a local variable, but decided not to.

They could have done - but only if they'd made sure that whatever the
compiler was targetting would give local variables the value "null" to
start with. (IIRC, this is true for the CLI.)

This is, of course, one of the problems with human language. It is subject
to interpretation. So, in fact, I don't think either of us is wrong about
what we are saying. One or both of us is just not trying hard enough to
understand the other!

Well, that's one of the purposes of specifications - to define what
terms mean as far as possible. In this case, the C# spec defines both
"null" and "unassigned variable" - and they are *not* the same thing
at all.

Jon

 

[Jon Skeet [C# MVP]]

It can be unassigned, if it is a member and not a local variable.

Not if it's a member of a reference type. In that case, it will be
definitely assigned according to the language specification.

If it's a member of a value type, the code should force you to
initialize that member before passing it as a parameter to a method.

The bottom line (the one that matters, in other words) is that the ideas I
expressed in my original reply were correct, but the words I used to express
them were parsed incorrectly by people for whom the reply was not intended,
for wahtever reason.

No, they were *not* correct in the only terms of reference which I
think can be said to be reasonably authoritative on such matters: the
C# language specification.

They may have been correct in some understanding of the terminology
which you have, but that could be said about anything. I could say
"string is a value type" and I'd be correct in the context of
terminology where value type actually meant what the C# spec deems a
reference type.

Many people say things like "objects are passed by reference by
default" - that's incorrect, even if they actually know what they mean
(the reference being passed by value). That's why it's crucial to have
a frame of reference such as the language specification, and in that
frame of reference your statement was fairly clearly incorrect.

<snip>

Jon

 

[Jon Skeet [C# MVP]]

Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
applicable" have never been identified with "null" in SQL or anywhere else.
When I mark a filed in SQL as "nullable", I am not doing it because I don't
know what value the user may want to put into the field. On the contrary, I
do it because I'm letting the user not put any value at all into the field.

Again "undefined", "unknown"," not applicable" does not equal "null". I
think this is super-important to be clear on, because "null" has a special
purpose and meaning and the minute you try to attach a meaning that is
something similiar, but not the same, to it, you confuse the issue and make
it more complicated than it need be.

Note that the same issue of confusion and complicated is true when
mixing the NULL of a database with the null of C#.
For instance, nulls are equal to each other in C#/.NET, but not in a
database (where you need IS NULL or whatever).

I think it's worth leaving databases out of the discussion, personally
- at least until we get into why nullable types were a widely
requested feature.

Jon

 

[Jon Skeet [C# MVP]]

Back when I started using C, Kernigan and Ritchie C, that is, which is the
"purest" form, when you declared an integer without assigning it, it didn't
have a value of 0. It had the value of whatever was in the memory location
that the compiler assigned it to. This was because C was not initially
designed to "fix things up" for inexperienced developers.

The fact that the C# compiler assigns a default value to an integer is
something built into the compiler.

Well, it's built into the language. Whether the compiler needs to do
anything to achieve that depends on the platform it's targetting. (For
the CLI, I don't believe it needs to do anything.)

So, again, we're talking English
semantics here rather than reality. In reality "null" signifies "nothing."

No, in reality "null"'s significance varies depending on the context.
The context here is either C# or the CLI, where it is "the special
value indicating an absence of an instance".

The same holds true for "null." The current abstraction level of computing
languages, C# in this discussion, can cause confusion when being talked
about using human language, as the abstractions approximate human ideas. So,
again, we're just having a semantic argument here, which I'm not sure is
useful.

I think the reason we're having an argument is because you're ignoring
the terminology used by the C# language specification. One of the
points of specifications is to remove the confusion and ambiguity
which arises out of terms not being well defined.

"null" is well defined in the spec, as is the concept of a variable
being definitely assigned. I've been using those terms as per the
spec, which anyone can read. You've been using them according to your
own internal understanding of them, as far as I can see, which no-one
else can read.

So, I will stand behind my statement that null signifies nothing, which
means that it signifies the absense of a value. One can not signify nothing
with nothing. It must be represented by something. Hence, the confusion.

No, the confusion was mostly when you started saying that a variable
with the value "null" was the same as an unassigned variable, and that
"null" isn't a value. Those statements are clearly at odds with the C#
language spec.

But, to put it more colloquially, how about trying to understand what I'm
saying, rather than mincing my words?

Okay, to put it bluntly back: why don't you start using terms in the
way the spec defines them, instead of in a way which isn't defined
anywhere? How do you expect people to understand you when you use
words/terms in a different way than the accepted/specified way?

When you talk about a variable with a null value being the same as a
variable which isn't assigned a value, it's reasonable for the reader
to think you might be using those terms in the accepted (specified)
way. According to that specification, your statements are incorrect,
plain and simple.

We all have different ways of talking
about things. But it is not the words we use that matter, as much as the
ideas they represent. Human language is not a programming language like C#,
where every token always means exactly the same thing, and there is no room
for interpretation. On the contrary, human language is all about
interpretation, nuance, and gist.

Hence the need for a specification, and hence the desirability of
everyone using terms in the way that the specification (whatever
specification is relevant in the context) defines.

Jon

 

[Scott M.]

I think you are making my point here. You introduced the concepts and
terms: "unknown", "undefined" and "not applicable" into the disussion. In
addition, you are talking about "why" a database needs the concept of a null
(I personally think you mis-stated that, but that is besides the point).

Below, you are talking about the practical use of null, rather than the
meaning of null, which is the point of this thread.

 

[Peter Duniho]

Something having an unknown value is not, in any way, related to a
dissussion of null. The very word you use "unkown" implies that there
is, in fact, something to "know". A null value indicates the exact
opposite of that, that there is no value at all. That's why I said
that your alaogy was not a good one.

IMHO, you are making a mountain out of a molehill.

The exact meaning of "null" depends on what the designer of the code using
"null" intends it to mean. While I do see the difference between
something having a price that is not known and something not having a
price at all, I see absolutely nothing wrong with someone writing code in
which "null" can mean the former. For example, suppose you have a
database of products available for sale. You know ahead of time that
*everything* has a price. Why in the world would you use "null" to
indicate something that has no price? Your set of data would never use
the value "null" in that case, and there would be no reason to even use a
nullable type.

"Null" means what the code designer says it means. Nothing more, nothing
less. Your complaint about the analogy provided is pointless. If someone
wants to use a "null" value to indicate that a value is unknown, rather
than to indicate that there is no value, what's it to you? How in the
world is it so wrong to do so?

When I run into situations where a value is unknown to me, I set up a
variable to capture that value. [...]

And what if according to your definition of "null", your variable will
never take on the value "null"? Then you've wasted extra storage for no
good reason.

You seem to be discussing what a "nullable type" is, rather than the
meaning of "null".

Given that "the meaning of 'null'" is arbitrary, while "what a 'nullable
type' is" is not arbitrary, it seems to me that the latter is a more
sensible thing to discuss.

Pete

 

[Patrice]

I will just end with how the SQL Server doc explains this.

http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
"Null values generally indicate data that is unknown, not applicable, or
that the data will be added later."

I'm not sure what is the point you don't like in this definition that looks
quite close to mine but it really looks like that understanding each other
on this topic is out of reach.

Take care and see you soon in another thread for another heated discussion
;-)

 

[Rory Becker]

I will just end with how the SQL Server doc explains this.

http://msdn2.microsoft.com/en-us/library/ms191504.aspx :

"Null values generally indicate data that is unknown, not applicable,
or that the data will be added later."

I really like that definition. It feels closest to what I think it should
mean.

 

[Scott M.]

I will just end with how the SQL Server doc explains this.

http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
"Null values generally indicate data that is unknown, not applicable, or
that the data will be added later."

I'm not sure what is the point you don't like in this definition that
looks quite close to mine but it really looks like that understanding each
other on this topic is out of reach.

What I don't like is exactly what I've been saying all along, we're not
talking about what a null value in SQL "INDICATES" (per your documentation).
So your definition and link are irrelevant. We are talking about the
DEFINITION of null in the .NET FRAMEWORK. What if another database's
documentation had a different description of null? Would that change your
understanding of what null means?

Take care and see you soon in another thread for another heated discussion
;-)

You too!

 

[Scott M.]

"Null" means what the code designer says it means. Nothing more, nothing

less. Your complaint about the analogy provided is pointless. If someone
wants to use a "null" value to indicate that a value is unknown, rather
than to indicate that there is no value, what's it to you? How in the
world is it so wrong to do so?

Because "null" is not a term that I coined, it is a well known programming
concept and it doesn't "mean" whatever the designer wants, it means "no
value at all" - nothing more, nothing less. That is not my definition, it
is the programming definition. Now, it would be fair to say that a designer
can *use* nulls as they see fit for their application, but the desinger
never gets to *define* the meaning of null.

Given that "the meaning of 'null'" is arbitrary, while "what a 'nullable
type' is" is not arbitrary, it seems to me that the latter is a more
sensible thing to discuss.

But it is not arbitrary, that is just plain wrong. See my above comments.
The meaning of "null" is not now, nor has it ever been arbitrary, the "use"
of nulls, yes, the "meaning", no.

 

[Kevin Spencer]

Jon,

Contentiousness is not my idea of time well spent. You win. I hope the OP
did.

--

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Kevin Spencer]

Well, that's one of the purposes of specifications - to define what
terms mean as far as possible. In this case, the C# spec defines both
"null" and "unassigned variable" - and they are *not* the same thing
at all.

Jon

Hm, remind me not to discuss the Bible with you at any time in the future.

--
;-),

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Jon Skeet [C# MVP]]

Because "null" is not a term that I coined, it is a well known programming
concept and it doesn't "mean" whatever the designer wants, it means "no
value at all" - nothing more, nothing less. That is not my definition, it
is the programming definition.

Um, it's not the definition in either the C# spec or the CLI spec. That
defines it as a special value which indicates the absence of an
instance. Quite precise, and not the same as "no value at all".

Could you give a reference to where your definition comes from and why
it should be seen as more authoritative than the C#/CLI specs in a
discussion about C# and the CLI?

Other languages can define it in other ways (C++, for instance, defines
null pointers, null characters etc) which is why it's worth sticking to
the specification of the platform/language in question.

 

[Peter Duniho]

[...]
But it is not arbitrary, that is just plain wrong. See my above
comments. The meaning of "null" is not now, nor has it ever been
arbitrary, the "use" of nulls, yes, the "meaning", no.

You are using the word "meaning" in an arbitrarily different way than I
am. The "meaning" of "null" as I am describing it is EXACTLY THE SAME as
what the coder using the "null" value to indicate and has ABSOLUTELY
NOTHING to do with the way that the language defines or implements a
"null" value.

You have decided to play word games with the intent of the word "meaning",
but that doesn't make your point any more valid. Your criticism of the
original analogy is still unfounded. If someone wants to use "null" to
mean that the price of an object is unknown, there's absolutely nothing
wrong with that. The language allows it, normal human semantics allows
it, and you have no standing to tell someone they can't do it that way.

Pete

 

[Scott M.]

But (again) that is SQL definition of what a null value *indicates*, not of
what a the *definition* of null is. It is also limited to SQL, not the .NET
Framework.

This documentation essentially says "Use null as an indication of the
following separate and different things...". That, in no way is a defition
of what null represents.

Wouldn't you agree that "an unknown value" could be a value of 27? Is 27
null? So, I would say that the documentation is actually poorly written
(wouldn't be the first time).

 

[Scott M.]

John, I'm not going to split unecessary hairs with you, yet again. Contrary
to your statement, I believe that (in programming terms) saying something
has no value at all and something not pointing to an instace are, in fact,
saying the same thing.

The point of my last comment is that the statement ""Null" means what the
code designer says it means." and the statment "Given that "the meaning of
'null'" is arbitrary" are both incorrect.

 

[Patrice]

If you don't know the value, you don't know it is 27 so you'll have a
"null" value anyway as you can't do better. Once you know the value is 27,
you'll have 27. I don't see how it would make 27 equal to null. Looks like
as simple as that to me.

Of course if you wanted to distinguish additional cases ("not know", "not
applicable" etc...) you would have to keep an additional value acting as a
marker but I've never have to do this myself until then.

My understanding is that the OP wasn't discussing the null C# keyword but
the 2.0 "nullable types" feature
(http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark
a value type as being "null"? I would be very inclined to think that it were
precisely introduced to match the NULL marker found DBMS sidea nd that
wasn't available .NET side for value types until now.

Finally I would think he was expecting a bit more than a "formal definition"
(what is yours ?) but sorry we are not allowed to tell you what this value
could "indicate" in practice in your code...

I have nothing to add...

--
Patrice

But (again) that is SQL definition of what a null value *indicates*, not
of what a the *definition* of null is. It is also limited to SQL, not the
.NET Framework.

This documentation essentially says "Use null as an indication of the
following separate and different things...". That, in no way is a
defition of what null represents.

Wouldn't you agree that "an unknown value" could be a value of 27? Is 27
null? So, I would say that the documentation is actually poorly written
(wouldn't be the first time).

 

[Jon Skeet [C# MVP]]

John, I'm not going to split unecessary hairs with you, yet again. Contrary
to your statement, I believe that (in programming terms) saying something
has no value at all and something not pointing to an instace are, in fact,
saying the same thing.

Do you not see how "no value at all" and "a special value" are
contradictions? According to the C# spec at least, null *is* a value.
To say it's not a value contradicts that.

If I do:

string x = null;

then the variable x has a value - the null value, which refers to no
instance.

If I do:

string x;

then the variable x has no assigned value yet, as far as C# is
concerned.

The point of my last comment is that the statement ""Null" means what the
code designer says it means." and the statment "Given that "the meaning of
'null'" is arbitrary" are both incorrect.

On that point I agree with Peter - that it's reasonable to say (in a
particular situation) what semantic meaning a "null" value has, how it
should be interpreted for that particular variable/return value etc. On
this point, it seems to me that you're the one splitting hairs.

 

[Jon Skeet [C# MVP]]

<"Patrice" <http://www.chez.com/scribe/>> wrote:

My understanding is that the OP wasn't discussing the null C# keyword but
the 2.0 "nullable types" feature
(http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark
a value type as being "null"? I would be very inclined to think that it were
precisely introduced to match the NULL marker found DBMS sidea nd that
wasn't available .NET side for value types until now.

I would largely agree, but soften the statement a little. It doesn't
really "match" NULL in the database, but it's often used to represent a
value which is NULL in a database (or which should be NULL after
insertion/update).

The rules for equality and logic are different to databases (and are
also different in different languages, IIRC). A good example of this is
the following program - it will produce output of "True", but a query
trying to match using "=" in SQL wouldn't work:

using System;

class Program
{
static void Main(string[] args)
{
int? x = null;

Console.WriteLine (x==null);
}
}

 

[Scott M.]

If you don't know the value, you don't know it is 27 so you'll have a

"null" value anyway as you can't do better....

NO! Stop right there. That is false! Just because I don't know the value
doesn't mean it can't have a value (like 27). Variables are great examples
of holders of potentially unknown values, that doesn't make all variables
null does it?

Of course if you wanted to distinguish additional cases ("not know", "not
applicable" etc...) you would have to keep an additional value acting as a
marker but I've never have to do this myself until then.

Again, you are making my point! You just said that to distinguish these
other possibilities, you need some value acting as a marker, null is not
sufficient for all these possibilities so how could your documentation be a
good one for null.

My understanding is that the OP wasn't discussing the null C# keyword but
the 2.0 "nullable types" feature
(http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to
mark a value type as being "null"? I would be very inclined to think that
it were precisely introduced to match the NULL marker found DBMS sidea nd
that wasn't available .NET side for value types until now.

Finally I would think he was expecting a bit more than a "formal
definition" (what is yours ?)

I'm pretty sure I've said this a bunch of times at this point:

null = no value

but sorry we are not allowed to tell you what this value could "indicate"
in practice in your code...

You could, but that wouldn't be a definition of null (as the OP asked "what
is actually a null value"). You have not provided a definition of null
anywhere in your replies, just places where you *could* use null. Strange
that you are asking me for something I've given, but not given yourself?

I have nothing to add...