Small Proposal "!in"

T.J. Crowder tj.crowder at
Thu Jul 19 13:44:07 UTC 2018

On Thu, Jul 19, 2018 at 12:32 PM, Andy Earnshaw
<andyearnshaw at> wrote:
> Although I support the idea of `!in` (for the same reasons as T.J. Crowder
> mentioned, plus it's useful for duck typing), what some browsers do isn't
> great argument as modern browsers follow the spec more closely with
> to inherited accessors like this and you'd never be able to use `!in` for
> older browser.

Well, there's transpiling.

> `!in` and `!instanceof` would be great additions to the operator sets.

AND, agreeing with Mike Samuel, an ergonomic operator for
`hasOwnProperty` (that
doesn't have the issues of being overridden, not being inherited because `
Object.prototype` isn't in the object's prototype chain, etc.) would be a
great addition. I don't see any reason they couldn't all be part of the
same proposal as they touch the same parts of the spec and implementations.
And agree that the own property ones would be the more useful ones, but
there are use cases for both.

The immediate temptation is `hasOwn` and `!hasOwn`. My only concern is that
their operands would be in the opposite order to `in` and `!in`:

const o = Object.create({a: 1});
o.b = 2;
console.log("a" in o);     // true
console.log(o hasOwn "a"); // false
console.log("b" in o);     // true
console.log(o hasOwn "b"); // true

For me, `hasOwn` with the different operand order isn't a problem, but
others may take a different view. Trying to keep the same order takes us
down a route like `inOwn` which I can't say I care for.

But I wonder if all of this discussion is useful. If someone *did* take the
time to work out the naming and do a proper draft proposal, perhaps a Babel
plugin, is there really any likelihood of someone championing it? I'd see
these contents:

* `name !in obj`, `name notin obj`, or whatever it gets called
* `obj hasOwn name`, `name inOwn obj`, or whatever it gets called
* `obj !hasOwn name`, `name !inOwn obj`, or whatever it gets called
* `Reflect.hasOwn`, the "own" version of `Reflect.has`
* `Proxy` trap for `hasOwn` (even if the operator has a different name)

Is there anyone appropriately-placed who can say "Yeah, if someone spends
the time to investigate this and put together a really proper proposal, I'm
willing to look at that proposal with an eye toward _possibly_ championing
it." I mean, if there's a 10% chance or better, it may be worth someone's
time. If there isn't, then...

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

More information about the es-discuss mailing list