I was speaking about C# this whole time so that’s part of the reason we seem to be missing each other. C# does not have a
Number class, and it is not possible to return a
null value for a
struct type. One of the goals is also to keep the API consistent across platforms. If we introduce this API into Java, what would C# do, and what would Objective-C do, etc?
No one has mentioned
getValue() yet either, which is the sort of end-all stop for this discussion and it will return an untyped object. If this value is
null then the value truly is a
null or it is missing. The “casting” between types here happens down at the C++ level, which has no concept of a “null int.” So when you request to get the value of a certain type, the platform will forward that request to the native C++ library and say “I want this value as X” and the C++ library will both simultaneously deserialize and attempt to cast the value.
My belief is that all of this can be handled at the app level. If you are concerned about the case you mentioned with the two devs, you could have it so that your initial data object has a value of -1 (for example). That way, if it is 0, you will know something is amiss. Ultimately the paradigm here is that you are managing your data object, and you should know what type the key contains. Maybe that way of thinking is too abrasive? All we do is store the data you give us, and attempt to give it back as the type you request.
I appreciate your point about wanting to know immediately when you have requested the wrong type. I think that if we decide to do this in the end that it will not be a 2.0 thing though. We’ve already bulldozed over deadline after deadline and it’s getting out of control. I believe that this can be handled in later releases without altering the API though (either via additions, or implementation changes).