I think the prevailing opinion was that one should use has_index() to determine if a mapping contains an index, and that undefinedp() would be used to determine if the value of the specified index is UNDEFINED. The rationale provided by those in favor is that currently, one must use a special object to represent an undefined value. 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".
Can you elaborate on how you envision this would break things?
Bill
Agreed upon, indeed? That's news to me. I object to this strongly, since it effectively and completely defeats the purpose of UNDEFINED. We could just as well remove it completely instead. That'd make one less zero type, at least.
The object case might be justified to keep since one can just as well use has_index, but not this.
A possibility is maybe that
a->b = UNDEFINED;
actually removed the index "b" from the mapping a, but even that is dubious for compatibility reasons (places where this change would break stuff are very difficult to locate).