Section 12.5.6 The typeof Operator
Table 34 — typeof Operator Results
According to the last row of the table, `typeof` called on a non-standard exotic object that does not implement [[Call]] may result in "function" nonetheless. I'm not able to think of a valid reason for such a behaviour, and it deceives the expectation that `typeof` produces "function" iff the object is callable.
Either such an object should not be permitted to have "function" as `typeof` result, or a NOTE should be added specifying that this is intentional.
Mark,
Do you agree that it is a bug that we didn't list "function" is the list of "must nots"?
Do you recall whether there were some know nonconforming host objects that we were trying to grandfather in.
Hi Allen, Claude,
I do agree that it is a bug. I do not remember if there was a host object counter-example. But even if there is, it seems we could grandfather it in by simply specifying that it does have a [[Call]] method that always throws.
(In reply to Mark Miller from comment #2)
> But even if there is, it seems we could grandfather it in
> by simply specifying that it does have a [[Call]] method that always throws.
There is a subtle difference between objects that have a [[Call]] method that always throws, and objects that don't have a [[Call]] method. For instance, let `f` be an object, and consider:
Function.prototype.bind.call(f, null)
That expression will throw an error iff `f` does not have a [[Call]] internal method (to a first approximation at least, for one can find several obscure ways for that expression to fail).
Good point. But probably there is no significant legacy constraint on preserving the throwing behavior of Function.prototype.bind.call(f, null) on these host objects. If the consequence attributing a [[Call]] method to these host objects is that the bind succeeds and the throwing is postponed until the bound method is called, I suspect we could get away with that.
fixed in rev28 editor's draft.
Added "function" to the list.
fixed in rev28