search

tc39 / proposal-is-error

ECMAScript Proposal, specs, and reference implementation for Error.isError
https://tc39.es/proposal-is-error/
MIT License
57 stars 2 forks source link

Proxies: to pierce or not to pierce? #8

Open ljharb opened 1 month ago

ljharb commented 1 month ago

Array.isArray pierces Proxies. This is widely regarded as weird. The current proposal pierces in the same way.

@bakkot has expressed a constraint that prior to stage 2.7, the proxy piercing be removed.

I suspect @erights @mhofman @kriskowal @gibson042 will have thoughts. Please express them here :-)

bakkot commented 1 month ago

Specifically, right now from the perspective of a creator of Proxies there are four kinds of things in the world: primitives (which can't be proxied), functions, objects, and arrays. Arrays are there only because of the Proxy-piercing behavior of isArray. I don't think we should make that list any larger, especially for some random type that isn't particularly foundational.

ljharb commented 1 month ago

There's more than that - there's "objects" and "objects with internal slots or private fields or closure-based receiver identity checking" - but I don't think that weakens your argument.

bakkot commented 1 month ago

Proxies don't need to distinguish between those things when choosing their target unless they're forwarding some operations to the target rather than implementing all the traps. The happy path for a Proxy is that the target is unrelated to the object that the Proxy is pretending to be.

ljharb commented 2 weeks ago

https://github.com/tc39/proposal-is-error/issues/7#issuecomment-2221669917

On the question of proxy piercing, this would make Object.prototype.toString conflict with Error.isError (since only isError will pierce), unlike Array.isArray which pierces in both places. I don't think that's a good idea.

I find this to be an additional strong argument against proxy piercing.

ljharb commented 1 week ago

I've put up #11 which removes proxy piercing.