21:41
<Michael Ficarra>
JSON.parse does an IsCallable check on reviver before passing it to InternalizeJSONProperty, but InternalizeJSONProperty types that argument as "a function object"
21:41
<Michael Ficarra>
esmeta rightfully complains because those types don't match up
21:41
<Michael Ficarra>
what should we do?
21:44
<Michael Ficarra>
🤔 though it's strange that it wouldn't complain about the same thing with Function.prototype.bind and BoundFunctionCreate...
21:45
<Michael Ficarra>
it's possible that it's already skipping one of those for some other reason, I'll take a look
21:46
<Michael Ficarra>
btw this would be easier if someone stamped https://github.com/tc39/ecma262/pull/3651 and we merged it
22:07
<bakkot>
rubberstamped, I am just going to trust that this does what it looks like and not try to actually check anything about github actions
22:08
<bakkot>
how does IsCallable not imply "a function object"?
22:08
<bakkot>
"A function object is an object that supports the [[Call]] internal method"
22:09
<bakkot>
IsCallable is true iff the argument is an object and has a [[Call]] internal method
22:10
<bakkot>

I guess we could tweak the prose of IsCallable to say "determines if argument is a function object", which would be an improvement over the current word salad:

a callable function with a [[Call]] internal method

but I don't think that would affect esmeta by itself

22:13
<Michael Ficarra>
esmeta says it could also be a Proxy object that implements [[Call]]
22:14
<jmdyck>
and that's a function object
22:17
<Michael Ficarra>
ah, fair
22:19
<Michael Ficarra>
this is why we should rename that to callable object, it's so unintuitive
22:20
<jmdyck>
rename "function object" to "callable object" ?
22:21
<ljharb>
but a callable object is a function
22:21
<ljharb>
a proxy for a function is also a function
22:22
<jmdyck>
See also https://github.com/tc39/ecma262/pull/2889