I agree that has_index is a neater way to check existence than zero_type, but that's beside the point.
The original intention with UNDEFINED (from long before it even had that name) was to be able to check the existence of an index and to get its value if it exists, both with a single indexing operation. UNDEFINED is the special result that signifies nonexistence, otherwise the value is returned. For this to work it follows that it must be impossible to store UNDEFINED in anything indexable. In the mapping case, the choice was made to silently strip off the subtype. Another more stringent approach would have been to throw an error instead. In the object case I suspect the problem was simply overlooked, but I don't know. I think UNDEFINED should keep this use. If the goal is to add nil, NULL, UNINITIALIZED or whatever then that's another value and another discussion. > This is mostly useful for the case where you want to know whether an > integer 0 was passed, or no value at all, particularly when mapping > between languages (SQL or JSON for example) where there is a > difference between 0 and "no value". In cases like that you really ought to have a different "no value" value on each abstraction level. Pike is one level, the sql/json module is another on top of it. A higher level should have its own "no value" which actually is a value on lower levels, so you can handle it in a natural way on the level where you are implementing the new level. In the general case there can be an arbitrary amount of abstraction levels and hence an arbitrary amount of "no value" values. E.g. in Roxen there can be three: Pike (with UNDEFINED), rxml (with RXML.nil) and the sql module (with SqlNull, coming in 5.0). All attempts to avoid this has only lead to tricky code, confusion, and bugs (I regret making RXML.nil and UNDEFINED interchangeable in many of the variable support functions in the rxml framework).
