In general in ES, undefined triggers defaults, whereas null does not. However apparently you can get default species behavior if you set species to null. This seems incorrect: it should throw a TypeError instead (since null is not a constructor).
WThe null or undefined test is consistent with the behavior of GetMethod and the GetMethod behavior was arrived at based upon discussions at TC39 meetings.
The undefined gets you default is a rule that is specific to destructuring (which includes function parameter processing)
Allen, are you saying that we will fall back to the default function in the case of GetMethod(obj, 'foo' defaultFunction) when obj.foo === null? I cannot recall us having this discussion. We did allow null in then(resolveHandler, rejectHandler) but that was mostly for backwards compat.
(In reply to Erik Arvidsson from comment #2)
> Allen, are you saying that we will fall back to the default function in the
> case of GetMethod(obj, 'foo' defaultFunction)
No, GetMethod doesn't even have a defaultFunction argument.
This is about what property values are are reported by GetMethod() (and other similar use cases) as no method found.
GetMethod
returns the property value if it is callable
returns undefined if the property value is undefined or null
Throws a TypeError for all other property values
Mostly, this about what value you use for situations like:
let itr = function*() {yield 1}().
itr.throw = undefined; // hide the inherited 'throw' method
itr.throw = null; // hide the inherited 'throw' method
//either of the above two lines will work
I'm pretty sure that when we talked about this pattern, people in TC39 thought that both null and undefined should be acceptable.
In fact, the change markup for GetMethod shows that the null case was added in the Rev26 and the release notes for Rev26 explicitly mention that change. I'm pretty sure, the change was based upon discussion at the preceding meeting.