int nan

[grauzone]

> Have you read my posts? I have said to use the value that currently is int.min as null, and I've explained why.

That wasn't very explicit. Anyway, we need int.min for, you know, doing 
useful stuff. We can't just define a quite random number to be a special 
value. Checking math operations for nullable integers would also be 
quite expensive (you had to check both operands before the operation).

If you realize nullable ints by making them a tuple of a native int and 
a bool signaling nan, for most operations you only need to or the 
nan-bools of both operands, and store it in the result. At least I 
imagine that to be better, because you don't need additional jumps in 
the generated asm code. And this implementation choice clearly is 
superior, because it doesn't restrict the value range of the original 
type. There's no int value, that the nullable int type can't represent.

Now there's the space overhead, but if you need performance, you'd 
restrict yourself to hardware supported operations anyway.

Although it's pointless to discuss about implementation details of a 
feature that will never be implemented, what do you think?


PS: I'd prefer "checked" math operations (as in C#, I think) over 
int.nan. Overflows or illegal operations would just trigger exceptions.