Small Proposal "!in"

Andy Earnshaw andyearnshaw at gmail.com
Thu Jul 19 14:09:18 UTC 2018


On Thu, 19 Jul 2018 at 14:44 T.J. Crowder <tj.crowder at farsightsoftware.com>
wrote:

> On Thu, Jul 19, 2018 at 12:32 PM, Andy Earnshaw
> <andyearnshaw at gmail.com> 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 a
> > great argument as modern browsers follow the spec more closely with
> regards
> > to inherited accessors like this and you'd never be able to use `!in`
> for an
> > older browser.
>
> Well, there's transpiling.
>

Good point.


> > `!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`:
>

I'm not against this at all.  I just think the arguments against `!in`
aren't really arguments against it.  Adding `!hasOwn` would give even more
weight to an `!in` proposal, I think.


> 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.
>

Nor me. I would argue for `on` (`'a' on b`), but that is a huge typo
footgun (especially for Colemak users) and maybe isn't clear enough about
its semantics.  I would argue that operators aren't camel cased in JS
though, so `hasown`/`inown`.


>
> 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...
>

`!in` and `!instanceof` are low hanging fruit (run the same steps as their
counterparts but flip the result), better off in their own proposal. I
don't know if you'd find a champion to do it, but I do think a lot of
people would find them convenient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180719/9f984b24/attachment-0001.html>


More information about the es-discuss mailing list