from tomvc.be@gmail.com:
15.3.4.2 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:
Function.prototype.toString.call(aProxy)
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:
Array.prototype.slice.call(aProxyArray,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: https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md.