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.
