Timeline for In .net, why can't values of intrinsic data types (such as DateTime) be null?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 2, 2011 at 2:14 | comment | added | ligos |
@ConradFrix: I Googled around but couldn't find any information about how a primitive scalar is actually stored in memory. The closest I can get is SqlInt32 (msdn.microsoft.com/en-us/library/…). Reflector tells me it has has 2 fields: an int and a bool.
|
|
| Dec 1, 2011 at 20:41 | comment | added | Conrad Frix | @EricLipper Oh, I don't doubt it, but I'd imagine the way that extra bit is stored could be different when the int is in a Table vs a variable in SQL Batch or Stored Procedure. I only mentioned it because the linked articles talked about null bitmaps in tables. | |
| Dec 1, 2011 at 20:19 | comment | added | Eric Lippert | @ConradFrix: If the integer is nullable then there is an extra bit stored somewhere, I promise. | |
| Dec 1, 2011 at 17:12 | comment | added | Conrad Frix |
@ligos. Nice but I'm also curious about how Declare @int as integer; SET @int = null works. It supposed to be 4 Bytes as well.
|
|
| Nov 10, 2011 at 2:28 | comment | added | ligos | @ConradFrix: The DB guys use extra bits too. Although, because databases store records rather than individual values, they (well, at least SQL Server's implementation) use a bitmask for each record (which groups all those extra bits needed into one place). A couple of links: sqlserverpedia.com/wiki/Table_and_Record_Structure sqlserverpedia.com/blog/sql-server-bloggers/… | |
| Nov 4, 2011 at 20:39 | comment | added | Conrad Frix | Thanks so much. I think that fairly neatly describes why nullable value types would have been a bad idea. It does make me wonder how the DB guys gets away it though. And I do remember that we didn't have generics. Sadly I didn't get to have Generics full-time until 8 weeks ago :P | |
| Nov 4, 2011 at 20:31 | comment | added | Eric Lippert | @ConradFrix: Now, if we're talking about decisions made in the past that we regret, I regret this one. It is deeply unfortunate that we chose to make nullable reference types and non-nullable value types. History has shown that ideally the type system would make how the value is copied and whether the type supports a missing value orthogonal. It would have made my life easier had .NET had nullable value types and non nullable reference types from day one. But you can't do everything in v1, and remember, we didn't even have generics. | |
| Nov 4, 2011 at 20:28 | comment | added | Eric Lippert | @ConradFrix: Here are your choices: (1) Make int a 32 bit value; reserve some of those values for null, making .NET int incompatible with many existing languages and thereby preventing platform adoptions, (2) Make a "32 bit" integer take up more than 32 bits; take an enormous performance hit every time you use an integer on a 32 bit machine; hardly anyone does that, right? or (3) make int non-nullable. Which would you choose? | |
| Nov 4, 2011 at 20:21 | comment | added | Conrad Frix |
I don't doubt that they have hidden bits or a special bit pattern, but from my perspective that's an implementation detail. I doesn't give me insight into why int x = null; isn't allowed. Was it to expensive in terms of perf? Was it something the dev community didn't want? Was it to ensure some types would be blittable?
|
|
| Nov 4, 2011 at 20:05 | comment | added | Eric Lippert |
@ConradFrix: Implementations of other type systems manage to put six pigeons into five pigeonholes and end up with one pigeon per hole? I would love to see such a type system! I could do all kinds of great things with something that could violate basic laws of arithmetic with impunity! But sadly, there is no such beast. Implementations of type systems such as you describe either have hidden bits somewhere to track nullability -- as Nullable<T> does in .NET -- or they change the range of a value such that not all bit patterns refer to a legal value -- as IEEE floats do to define NaN values.
|
|
| Nov 4, 2011 at 18:26 | comment | added | Conrad Frix | +1 But I'm still confused about what is the real limitation is. Other type systems have similar "simple" types that have the same defined storage and yet support null semantics. It seems to me that V1.0 CLI specification authors did not arbitrarily chose to define values types the way they did. Can you give any insight into that? | |
| Nov 4, 2011 at 15:55 | history | answered | Eric Lippert | CC BY-SA 3.0 |