Calling toString on function proxy throws TypeError exception

Tom Van Cutsem at
Thu Oct 22 20:38:08 UTC 2015

2015-10-22 21:03 GMT+02:00 Mark Miller <erights at>:

> Ok, that all makes sense and is fine with me. Thanks for clarifying.
> Tom, I'm still curious what you remember?

What I remember is that the original direct proxies spec did the
transparent forwarding. still seems to be down, but an
archived copy of late 2014 (thank you Wayback Machine) shows that the draft
spec indeed specified forwarding:


* Function.prototype.toString ( O ) *

When called on a Proxy that is callable (i.e. whose target has a [[Call]]
internal method), returns the result of applying the built-in
Function.prototype.toString on the Proxy’s [[Target]]. Otherwise, throw the
same TypeError that would be thrown if this function is applied to a
non-function object.

For a revoked proxy, IsCallable is false so this operation throws a

I cannot recall any specific discussions on why that behavior was changed
to throwing a TypeError instead. The only reason I can come up with is that
it could be deemed a violation of the proxy's encapsulation in that it
should not leak such details about its target object.

I think it would be useful to at least reconsider the original forwarding
behavior. I think that in practice, forwarding toString() to the target is
not harmful, and the more places where code throws on a Proxy, the less
useful Proxies become altogether.

I noticed there is a stage 1 proposal to revise the specification of
F.p.toString() <>,
including standardizing its behavior for host objects. Perhaps the behavior
of F.p.toString() when applied to (function) proxies can become a part of
this revision effort?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list