Concerns around `Proxy.isProxy`

[caridy]

One of the "features" of proxies is that they are not observables, you can't really determine if an object is profixied or not, and I believe this is something we want to preserve. I suspect @erights has more to say about this.

Additionally, I believe this proposal is about identity discontinuity, and determining if an object is a proxy or not does not qualify as so since the object should pass the identity test when compared to its proxified version.

When looking at the motivations:

Why have a separate Proxy.isProxy() function? For the simple reason that Proxy objects do not act like anything else. The use case justifying Proxy.isProxy() is that, when debugging, it can often be necessary to know if the an object of interest is a Proxy or not.

I don't think that justify the feature, specially when browsers (and probably node will do the same) are providing formatters for console to represent them accordingly. E.g.: I can define a new formatter via window.devtoolsFormatters alongside a weakmap to show my own proxies differently in the console.

My recommendation is to spin out the Proxy.isProxy into its own proposal that we can debate on its own.

[ljharb]

@bakkot recently showed me a technique, per spec, that makes it possible to build an isProxy function on any non-frozen object - by leveraging setPrototypeOf cycle detection. Separately, anything that already has a brand check pass on it, won't pass on the proxy for it.

That said, I agree that this should probably be a separate proposal, if for no other reason then because it will be very contentious.

[jasnell]

Ok, I have no problem with separating it out.

[erights]

by leveraging setPrototypeOf cycle detection

Yes, that is indeed a bug we need to fix. At some point we will turn https://github.com/tvcutsem/es-lab/issues/21 into a proposal. This will also make many uses of proxies much faster.

Attn @tvcutsem