This is the first of a weekly three part se­rie of posts about Nullable. In these posts I want to de­scribe the rea­sons be­hind three de­sign choices:

1. Why not just use SQL se­man­tics for null?
2. Why null == null does­n’t im­ply null >= null and null <= null?
3. Why in­side a generic class with a type pa­ra­me­ter t the ex­pres­sion t == null will re­turn false, when t is a nul­lable type and the value of it is null.

Let’s start from the first ques­tion as the an­swer is shorter. We’ll get to the other two in the com­ing weeks.

The first ques­tion re­lates to the rea­son not to have the same se­man­tics as SQL for re­la­tional op­er­a­tors. The SQL se­man­tics have been com­monly re­ferred to as three-value logic where null == null re­turns null. Introducing such logic in the C# lan­guage would be prob­lem­atic. The main rea­son is that the lan­guage al­ready con­tains the con­cept of null for ref­er­ence types and it does have the pro­gram­ming lan­guages tra­di­tional two-value logic where null == null re­turns true.

Granted that we can­not change this de­f­i­n­i­tion, then the ad­di­tion of three-value logic just for some types would be con­fus­ing. We would need, for ex­am­ple, to cre­ate a new NullableString class to be able to ap­ply three-value logic op­er­a­tors to it. More gen­er­ally, the pres­ence in the same code of two value logic and three value logic op­er­a­tors would make the code quite dif­fi­cult to write, read and main­tain.