« Bugzilla Issues Index

#1264 — Function.prototype.toString: should callable proxies should have special toString behavior

from Function.prototype.toString

Perhaps this is still on your TODO list, but I would advise to specify what this method should do on a Proxy. My suggested semantics:

"When called on a Proxy that is callable (i.e. whose [[ProxyTarget]] has a [[Call]] internal method), return the result of applying the built-in Function.prototype.toString on the Proxy’s [[ProxyTarget]]. Otherwise, throw a TypeError. When applied to a revoked proxy, throw a TypeError."

I guess I don't see why.

toString is just a method and it is going to be automatically forwarded unless the handler does something explicitly otherwise.

Similarly, for a revoked proxy it would be handled like any other property access.

Why is special handling needed?

Of course, `aProxy.toString()` will just be forwarded (or intercepted by the get trap).

I'm particularly thinking about:

For this, if we don't specify anything, it'll be up to the implementation. For proxies, I think forwarding to the target if the target is a function is the logical choice. But AFAICT, we need to specify this explicitly.

Isn't this a general issue for any (non-generic) method that is explicitly invoked via call/apply?

For example:,5)

(slice would actually work because it is generic, but anything that actually need something that was a real array would have the problem)

In one sense this is similar to the problem with using discrete [[Get]] and [[Call]] steps to do method invocation. Without visibility of the [[Get]], the [[Call]] doesn't know whether a proxy to target translation need to take place.

Do we need to elevate this to esdiscuss?

I'm happy to take this to the list.

For most built-in methods, there is indeed no need to specify any special behavior for proxies, as those internal methods (especially those of Array.prototype) just use the MOP (i.e. calls to [[Get]] etc.), so can work with proxies as well.

Function.prototype.toString is special in that its definition falls outside of the scope of the MOP. In particular, it is explicitly marked as a "non-generic" method. As its behavior is already mostly implementation-dependent, we could leave it at that, but I think prescribing the behavior for proxies is non-problematic and would avoid unnecessary incompatibilities.

Proposals should use the proposal process documented here: