Nullable trilogy Part I: why not just SQL?

-

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 semantics for null?
  2. Why null == null doesn’t imply null >= null and null <= null?
  3. Why inside a generic class with a type parameter t the expression t == null will return false, when t is a nullable 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.

 

Tags

2 Comments

Comments

aBlogByGus

2005-01-21T04:47:00Z

If the mix­ture of the word ‘nullable’, ques­tion marks, and C# are in­ter­est­ing to you then you you might want to check out the blogs of a cou­ple of my peers: Peter (C# Compiler Dev lead) and Luca (C# Compiler…